Legacy VPN and perimeter models break auditability and segmentation because they grant broad network reach after login instead of proving narrow, session-specific authorization. Under DORA, that is not enough. Financial institutions need access that can be verified, logged and revoked at the identity and session level, not just hidden behind the network boundary.
Why legacy VPN and perimeter access fails under DORA
Legacy VPN and perimeter access models assume that network location is a good proxy for trust. Under DORA, that breaks down because third-party access must be governable as an ICT risk, not just as a connectivity problem. Once a supplier is inside the tunnel, the model often cannot show who was allowed to do what, for how long, or under which business justification.
That is why the weakness is not just “remote access is old”, it is that broad network reach hides the control decisions DORA expects firms to demonstrate. If the access path cannot be tied back to identity, purpose, and session boundaries, it is hard to prove least privilege, continuous oversight, and timely revocation.
What legacy VPNs conceal about third-party access
A VPN typically authenticates a user or device at entry, then extends a wide internal network surface. That is useful for reachability, but poor for third-party governance because the control boundary sits at the tunnel, not at the application, action, or session. The result is a large trust zone where access can be overbroad, difficult to audit, and slow to revoke when a supplier relationship changes.
This is also where segmentation gaps become operationally visible. A third party who only needs one application may still inherit access to adjacent systems, internal shares, or administrative paths. In practice, that creates a mismatch between the access granted and the access actually needed, which is exactly the kind of control weakness modern resilience rules are designed to surface.
- The access event may be logged, but the meaningful business activity inside the tunnel often is not.
- Revocation may require disabling a VPN account or certificate, but not necessarily every downstream path opened by that access.
- Network segmentation may exist on paper while the VPN still collapses too many applications into one trust boundary.
What DORA expects instead
DORA pushes firms toward provable control over access, third-party risk, logging, and resilience testing. For third-party access, that means access should be narrow, time-bound, reviewed, and attributable at the identity and session level. The control objective is not simply “can the vendor connect”, but “can the firm evidence exactly what the vendor could reach, when, and why”.
That makes identity-centric access patterns more defensible than perimeter-centric ones. A usable design lets the firm bind supplier access to a specific identity, an approved purpose, a short-lived session, and a revocation path that actually works when risk changes. The Third-Party, B2B and Contractor Access Guide is a practical NHIMG reference for the access-governance side of that problem, while the Financial Services Identity Security Guide shows how those controls fit financial-sector obligations.
Under DORA, the difference matters because auditability and operational resilience are not optional extras. If a supplier can only be managed through a shared network boundary, you may be able to grant access, but you cannot reliably prove that the access was constrained, monitored, and removed with sufficient precision.
How to recognise the control gap in practice
Legacy VPN becomes a problem when it is used as the primary third-party control rather than as one component of a broader access model. The warning signs are broad tunnel access, standing vendor accounts, manual revocation, and no clean way to separate application use from general network presence. That is especially weak where suppliers support multiple environments or where privileged work is performed through the same remote access path.
A better model makes access decisions at the point of use. The session should be attributable, the destination should be explicit, and the access should expire or be re-authorised when the task ends. That is why Remote Access Identity Guide and IAM and IGA Basics are relevant: they explain the shift from network trust to identity-governed access, reviews, and entitlement control.
The practical test is simple. If you cannot answer who the third party was, which exact resource they touched, and how quickly that access could be withdrawn, the control is too coarse for DORA-grade governance.
Risk and Threat Considerations
Legacy VPN and perimeter models enlarge the blast radius of any credential compromise, vendor error, or abused third-party account. Once an attacker or misuse path gets through the tunnel, broad internal reach can turn a single access failure into lateral movement, data exposure, or operational disruption.
Failure mechanism: The control assumption is that entry into the network is enough to justify downstream trust, so segmentation, session scoping, and action-level authorisation remain too weak to contain misuse or compromise.
Impact: Firms can lose auditability, overexpose internal systems, and struggle to prove timely revocation or least-privilege access when regulators, auditors, or incident responders ask for evidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the technical controls, while DORA defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | Digital Operational Resilience Act | DORA governs ICT third-party risk, logging and resilience for financial entities. |
| Recommendation — Map third-party access to ICT risk controls and require auditable, revocable access paths. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Zero trust replaces perimeter trust with explicit session and access verification. |
| Recommendation — Enforce explicit, per-session verification and narrow access boundaries for suppliers. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Third-party VPN access often exceeds the minimum access needed for the task. |
| AU-2 — Event Logging | DORA-grade oversight depends on traceable access and session evidence. | |
| IA-5 — Authenticator Management | Legacy VPN models often fail on credential lifecycle and revocation control. | |
| Recommendation — Restrict supplier access to the minimum permissions needed for each approved task. Log third-party access events at a level that supports audit and incident review. Manage and rotate supplier authenticators so access can be revoked promptly. | ||
Practitioner Guidance
What to prioritise: Replace “vendor on the VPN” with a model that makes every third-party session specific, short-lived, and reviewable. The first remediation target is usually the broadest supplier path that combines persistent access with the largest internal reach.
What to verify: Confirm that third-party access can be demonstrated at three layers, identity, session, and resource. If your logs only show tunnel entry and exit, you do not yet have enough evidence for strong DORA-aligned oversight.
Common mistake: Treating MFA on the VPN as the end of the control story. MFA reduces login risk, but it does not by itself solve excessive reach, poor segmentation, or weak revocation.
Practitioner takeaway: Under DORA, the question is not whether a supplier can get onto the network, it is whether the firm can prove that supplier access was narrowly authorised, continuously bounded, and fully revocable.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org