Scaling remote access without moving the bottleneck

A remote-access platform can be technically available while remaining unusable at the start of the working day. Rapid expansion should be treated as a capacity, identity and operations programme—not simply the purchase of additional VPN licences.

Model concurrency before appliance throughput

Begin with people and workloads. Record the expected number of concurrent users by hour, the applications they use, session duration, transfer patterns and whether voice or video will traverse the corporate network. Published firewall figures normally describe favourable packet sizes and limited security inspection; they are not a promise of usable encrypted throughput with threat prevention enabled.

Calculate the complete path: internet circuit, edge appliance, VPN termination, authentication services, internal firewalls, DNS, proxy, application tiers and storage. Apply a realistic headroom allowance and model the morning reconnection peak separately from steady state. A platform sized for average bandwidth can still fail when several thousand clients authenticate and refresh policy together.

required_capacity =
  concurrent_sessions
  × measured_bandwidth_per_workload
  × encryption_and_inspection_factor
  × operational_headroom

Remove hidden single points of failure

A pair of VPN gateways is not resilient if both depend on one upstream circuit, one switch stack or one RADIUS server. Trace authentication and name resolution as carefully as the data path. Remote clients may establish a tunnel successfully and still be unable to locate a domain controller, resolve an internal application or renew credentials.

Place redundant authentication services where both gateways can reach them and test loss of each dependency. Confirm certificate revocation behaviour when public connectivity is impaired. If the remote-access portal depends on internal DNS, document how an engineer reaches it during the very outage the platform is intended to support.

Choose split tunnelling deliberately

Full tunnelling gives central security controls visibility over all client traffic but can double-haul cloud collaboration, software updates and streaming media through a constrained datacentre. Split tunnelling preserves capacity by sending selected internet traffic directly from the endpoint, but it changes monitoring, filtering and incident-response assumptions.

Make the routing decision by application and risk. Publish narrow, reviewed destination sets for high-volume trusted services and keep sensitive corporate traffic inside the tunnel. Protect the endpoint with host firewall, malware controls, disk encryption and current patches. Avoid broad exclusions based only on a vendor name; cloud address ranges and dependencies change.

Strengthen identity without creating lockout

Require multi-factor authentication for remote access and remove shared accounts. Define enrolment, replacement-device and lost-token procedures before expanding access. Helpdesk staff need a controlled method to verify identity without bypassing the factor that provides the protection.

Use conditional policy carefully. A rule that depends on a managed device certificate is effective only if certificates renew away from the office and the management channel works before the VPN connects. Test password expiry, first login, disabled accounts and users whose cached workstation credential no longer matches the directory.

Roll out in observable stages

Create pilot groups that represent different locations, devices and business applications. Increase concurrency in planned steps while watching tunnel count, CPU, memory, packet loss, authentication latency, DNS response time and application performance. Retain a stable client package and configuration during each step so faults can be attributed.

Provide users with a short readiness check covering broadband stability, supported operating systems, MFA and the distinction between local and corporate services. Do not make end users diagnose routing tables. Collect connection diagnostics centrally and give support teams a decision tree that separates home-network problems from authentication, tunnel and application faults.

Practise failure while demand is controlled

Test gateway failover, circuit loss, authentication-node loss and certificate expiry with real clients connected. Confirm how long sessions take to re-establish and whether users must intervene. Monitor licence ceilings and certificate dates alongside technical health; either can create a complete outage on otherwise healthy equipment.

Finish with an operating record: architecture, routing policy, supported clients, capacity assumptions, dashboard thresholds, supplier contacts, recovery steps and an owner for every exception introduced during rapid deployment. Temporary access has a tendency to become the permanent remote-working platform.