VPN, always-on VPN, and integrating security through APIs

Why this matters

This lesson closes objective 2.4 with two subjects that look unrelated and share a property worth noticing: both are mechanisms that grant durable access, and both are routinely deployed with far broader reach than the requirement needed.

A remote-access VPN typically places a device on the corporate network with whatever reach that network permits — which, in the flat estates the previous lesson described, is everything. An API integration typically holds a long-lived credential with whatever permissions made it work on the first attempt. In both cases the thing being examined is scope.

The second theme is about where access control now lives. A VPN is a network control, and network position has stopped being a reasonable proxy for authorisation. Understanding why a VPN is no longer the access control — while remaining a useful network control — is the bridge into deperimeterization and zero trust, which are the next two lessons.

The lesson

Site-to-site and remote-access VPN, split tunnelling and what it exposes

Site-to-site VPN joins two networks — office to data centre, data centre to cloud, organisation to partner. It is infrastructure: always up, transparent to users, and its security question is what the two sides can reach through it. A partner tunnel that terminates into the general corporate network extends your trust boundary around their estate, which is lesson ten's acquisition problem arriving by a different route. The control is termination into a restricted segment with enumerated flows, not into the core.

Remote-access VPN connects a user's device to the network. Its security questions are who is authenticating, what the device's state is, and what the session may reach.

Split tunnelling is the decision about which traffic goes through the tunnel.

• Full tunnel sends everything, including internet traffic, through the corporate network. This preserves egress inspection, proxy policy and data loss prevention for remote users — the controls that only exist at the corporate egress point. It costs bandwidth, adds latency, and degrades conferencing and SaaS performance, sometimes badly enough that users disconnect from the VPN to work, which is the outcome that makes the strict option the less safe one.
• Split tunnel sends only corporate-destined traffic through, and everything else direct. Performance is better, and the device is now simultaneously on the internet and on the corporate network, with no corporate inspection of the internet half.

The examinable trade is not "split tunnelling is insecure". It is that split tunnelling moves the enforcement point from the network to the endpoint. If the endpoint carries its own inspection, policy and detection — or if internet traffic is routed through a cloud-delivered security service, which is what SASE does in the next lesson — the loss is small. If the endpoint carries nothing, the loss is every egress control the organisation has.

One further exposure worth naming because scenarios use it: a split-tunnelled device is a path between the internet and the corporate network, so a compromise of the device bridges the two. That is an argument for endpoint posture and for segmentation of what VPN clients may reach, rather than for full tunnelling.

Always-on VPN: posture before access, and the failure mode when the tunnel is down

Always-on VPN establishes the tunnel automatically, before or immediately after user logon, and keeps it up without the user choosing to connect. Two genuine benefits follow.

Management continuity. Devices remain reachable for patching, configuration and inspection continuously rather than only when a user decides to connect. The device that goes months without policy because its user works offline is a real and common gap, and this closes it.

Policy cannot be avoided. Where the VPN is the enforcement path, a user cannot opt out of it by not connecting.

Posture checking is what usually accompanies it: before the session is granted, the device is evaluated — patch level, disk encryption, endpoint protection running and current, configuration compliance — and access is granted, restricted to a remediation segment, or refused. This is where the VPN starts to resemble zero trust, and it is also where its limits show, because the posture check is typically performed at connection and not re-evaluated, whereas the property it measures can change mid-session.

The failure modes are the examinable part:

• Fail-open versus fail-closed. If the tunnel cannot be established, does the device work without it? Fail-closed is the secure choice and it means a VPN outage is a complete outage for remote staff, which makes the VPN concentrator a single point of failure for the organisation's ability to work. That is an availability decision that belongs to the business, informed by the BIA from lesson eight.
• Captive portals. Hotel and airport networks require interaction before internet access, which an always-on fail-closed configuration prevents. A restricted pre-tunnel mode is the usual answer and it is a deliberately created exception.
• Concentrator capacity, which became a visible risk when remote working scaled abruptly and is a plain capacity-planning obligation.
• Sessions are long. Always-on means a session that persists for days, so session lifetime, re-authentication interval and continuous posture evaluation matter more, not less.

The conclusion a scenario is usually reaching for: always-on VPN is a substantial improvement over user-initiated VPN, and it is still network-level access granted once and held. Where that is insufficient, the answer is per-request authorisation, which is lesson twenty-five.

Why a VPN is a network control and increasingly not the access control

The reasoning worth being able to state, because it underpins the rest of the domain.

A VPN answers one question: may this device join this network? Historically that was an adequate proxy for authorisation, because everything valuable was on that network and being on it implied vetting. Three changes broke the proxy:

• The assets left. SaaS, cloud and partner-hosted services are not on the corporate network, so a tunnel into it grants access to a shrinking share of what people use. Backhauling SaaS traffic through the corporate network to preserve a control model is the tail wagging the dog, and it is the inefficiency SASE exists to remove.
• The users left. Remote and mobile working means network location correlates with nothing — a connected device may be in an office, a home, or an attacker's hands.
• Inside stopped being safe. Once an attacker has any foothold, they are inside the perimeter, and a control that authorises by network position authorises them too. This is the argument for the previous lesson's east-west policy and for the next-but-one lesson's zero trust.

So the accurate statement is: a VPN remains a good network control and a poor access control. It protects traffic in transit, joins networks that must be joined, and reaches systems that have no other access path — legacy applications, management interfaces, infrastructure. It should not be the thing that decides whether a user may open a particular application, because it cannot see the application, the request, or the sensitivity of what is being asked for.

The practical architecture that follows, and the one scenarios reward: keep the VPN for what it is good at, move application access to per-application authorisation that evaluates identity, device and context per request, and shrink what the VPN reaches to the set of systems that genuinely require network adjacency.

API integration between security tooling, and authenticating machine to machine

The second half of the objective, and it is where a modern security programme is actually assembled.

Security tooling is only as good as its integration: a vulnerability scanner whose findings do not reach the ticketing system produces a report; the same scanner integrated produces owned, tracked, measurable work. The integrations that carry most value:

• Identity provider to everything, so access follows one lifecycle.
• Asset inventory to scanner, so scan scope is derived rather than maintained — the dependency lesson five established.
• Scanner and posture tools to ticketing, so findings become work with owners and dates.
• Everything to the SIEM, so detection has the sources domain 4 needs.
• SIEM to response tooling, which is the SOAR material in domain 3.
• Threat intelligence in, and indicators out.

Machine-to-machine authentication is the security question, and the options rank clearly:

1. Workload identity / federated short-lived tokens. No stored secret, scoped to a specific workload, automatically expiring. Strongest, and the answer wherever the platform supports it.
2. Mutual TLS with managed certificates. Strong, with a real certificate lifecycle obligation — an expiry is an outage, as lesson thirty-one covers.
3. OAuth client credentials with short-lived tokens from a secrets manager. Workable and common.
4. Long-lived API keys. Widespread, weakest, and the thing most often found in a repository or a build log. Where they are unavoidable, they need rotation, restriction by source, minimum scope and monitoring for use from unexpected places.

Two design rules that scenarios probe. Least privilege per integration: an integration that needs to read findings should not hold a credential that can delete them, and tooling credentials are routinely granted administrative rights because that is what made the first test pass. And integrations are assets, with owners and expiry, from the previous lesson — an integration to a tool the organisation stopped using two years ago frequently still holds live credentials.

Rate limits, schema changes and the integration that fails silently

The operational reality, and the reason integrations degrade without anyone noticing.

Rate limits. APIs throttle. An integration that does not handle throttling with backoff and retry will drop data, and — this is the part that matters — usually drops it quietly, because the failure is a response code inside a loop nobody watches. An integration pulling a full inventory hourly may succeed in a small estate and silently truncate in a large one, producing a scan scope missing exactly the accounts that make it large.

Pagination. The closely related failure: an integration that reads the first page and treats it as the whole result. It works perfectly during testing and under-reports in production forever. This is worth naming specifically because it produces confident incompleteness — a coverage claim that is wrong in the safe-looking direction.

Schema and version changes. Providers change field names, deprecate versions and alter response shapes. A tolerant parser keeps working and quietly stops populating a field; a strict one fails loudly, which is better. The examinable preference is fail loudly over degrade quietly, because a security integration that reports nothing looks identical to one that has nothing to report.

Credential expiry. Certificates and tokens expire. The integration stops, and if nothing monitors the integration itself, the first sign is an audit finding months later.

The control that covers all of these is a freshness and volume check on every integration: when did this last deliver data, and was the volume within expected bounds. That is the same idea as lesson nineteen's requirement that evidence carry an age, applied here as monitoring. Two failure signatures to distinguish, because they need different fixes: no data usually means credentials or connectivity; plausible but reduced data usually means pagination, throttling or a schema change — and the second is far more dangerous because everything downstream continues to look healthy.