The Branch Hotspot Problem: When Outage Workarounds Break NRB Network Controls

When a branch's primary link drops and staff tether a phone to keep posting transactions, the bank has built an unmanaged network path into its core systems. That path is not on the network map. It does not pass through the branch firewall. Nobody is monitoring it. Nepal Rastra Bank's guidance has no exception for "the link was down." The fix is not a stricter memo. Engineer branch failover so the workaround is never needed, then make sure it is never possible.

Why this is a governance problem, not a branch problem

Branch staff who tether during an outage are trying to keep serving customers. The failure belongs to whoever designed a branch network with one path and no tested fallback. NRB's IT Guidelines (Bank Supervision Department, August 2012) are direct about it. Section 8, item 9 says the datacenter, disaster recovery solution, enterprise network and security, and "branch or delivery channels should be designed and configured for high availability and no single point of failure."

A branch with one link and no failover has a single point of failure by design. When that link fails, the business still has to run. So staff improvise. The improvised path then breaks several other requirements at once.

What the improvised path violates

Read the controls against a phone hotspot carrying branch traffic.

IT Guidelines 2012, Section 2 (Information Security):

• Item 9 requires strong cryptography and end-to-end encryption to protect customer PINs, user passwords and other sensitive data "in networks and in storage." A hotspot is a network the bank does not control.
• Item 10 requires firewalls between internal and external networks and between geographically separate sites. A tethered PC bypasses the branch firewall entirely.
• Item 21 requires the bank to evaluate security risk and apply additional controls when using wireless networks. An ad hoc hotspot is a wireless network nobody evaluated.

Cyber Resilience Guidelines 2023 (CRG):

• Para 38 asks for a network map that identifies links with the outside world. The hotspot link is not on it.
• Para 39 requires risk assessments before deploying new or updated technologies, products, services and connections. An emergency tether gets no assessment.
• Para 55(a) requires secure network protocols and encryption for information exchanged within the network and beyond, including remote connections.
• Para 60(a) asks for a secure boundary with trusted and untrusted zones and a deny-all, permit-by-exception policy between zones where possible. A tethered endpoint sits on both sides of that boundary at once.
• Para 77(c) and (d) call for continuous monitoring of network traffic, including remote connections, and comparison against expected traffic. Traffic leaving through a phone never reaches the sensors.

The CRG applies to institutions licensed by NRB's Payment Systems Department: A, B, C and D class BFIs, payment system operators and payment service providers. Every licensed BFI with a branch network is inside that scope.

The failure mode: the invisible link

Name the failure precisely: the invisible link. It is a connection that carries production traffic but appears in no inventory, no firewall rule base and no monitoring baseline. It is worse than a known weak link. A known weak link can be risk-accepted, compensated and watched. An invisible link cannot be governed because nobody responsible for governance knows it exists.

A known weak link can be risk-accepted. An invisible link cannot be governed at all.

Invisible links outlive the outage. A hotspot used once and never challenged becomes the branch's informal plan B. Staff learn that it works. The next outage, it gets used faster.

An illustrative scenario

The following is a composite scenario built for illustration, not a reported incident. A rural branch loses its leased line during a festival week. The ISP estimates a day to restore it. The branch manager asks a staff member to share their phone's data connection with the teller PC so cash deposits can post. The teller PC now has two routes: one dead link to the head office and one live link to the public internet through a personal device. Endpoint controls designed for a managed LAN may not apply. Head office monitoring sees the branch go silent and assumes it is offline. Transactions keep posting. Nobody at the head office can see how.

The bank has no way to answer basic questions afterward. Which systems did that PC reach? Over what path? Was the session encrypted end to end? The logs that would answer them were never collected.

Engineering the workaround out

Policy alone will not stop a branch from improvising during an outage if the business pressure is real. Take away the reason, then take away the means.

Ordered steps for IT and network leads:

1. Inventory branch connectivity. For every branch, record the primary link, any secondary link, and whether failover has been tested. Branches with one path are your exposure list.
2. Provide a managed secondary path. Use a bank-owned and bank-configured backup link that terminates on the branch's managed edge device, not on an end-user PC. It goes into the network map (CRG para 38) and the monitoring baseline (para 77).
3. Encrypt the tunnel regardless of carrier. Treat every branch-to-head-office path, primary or secondary, as untrusted transport. Carry traffic inside an encrypted tunnel that terminates on bank-controlled devices (IT Guidelines Section 2, item 9; CRG para 55(a)).
4. Test failover on a schedule. Pull the primary link at a sample of branches and confirm traffic moves to the secondary path without staff action. Record the result. An untested failover is a hope, not a control.
5. Block the improvised path. Restrict network interface changes and USB or wireless tethering on teller and branch PCs through endpoint policy. Alert when a branch endpoint acquires a new default route.
6. Write the outage procedure staff will actually follow. Tell branch staff exactly what to do when the link fails: who to call, what manual fallback applies, which transactions wait. If the procedure is silent, people fill the gap themselves.
7. Assess before you connect. Any new branch connectivity option goes through the pre-deployment risk assessment the CRG expects in para 39, before rollout and not after the first outage.

Checks for an internal or IS audit

Audit teams can test for invisible links without waiting for an incident.

• Compare branch endpoint network configuration against the approved baseline. Look for unexpected interfaces, adapters or routes.
• Review endpoint logs for tethering or new wireless connections on branch machines.
• Match branch transaction timestamps against head office link-status records. Transactions posting while the branch link was down need an explanation.
• Ask branch staff, without blame, what they did during the last outage. The answer tells you whether the documented fallback is the real one.
• Confirm that the steering committee the CRG expects has seen branch connectivity risk at least once. See the CRG steering committee post for how that committee should work.

If the invisible link is found during an incident instead of an audit, reporting obligations start immediately. Incident reporting under the CRG covers what that means in practice.