DORA exposes the limits of legacy access models

At a glance

What this is: This article argues that DORA exposes the limits of legacy access models by requiring continuous, auditable control over third-party access in financial environments.

Why it matters: IAM and PAM teams need to treat third-party access as a resilience and compliance problem, because DORA raises the bar from periodic review to real-time proof of control.

Context

DORA, the EU’s Digital Operational Resilience Act, changes access governance from a perimeter problem into a regulated accountability problem. Financial firms must now prove that third-party access is secure, traceable, segmented and continuously monitored across hybrid environments.

Legacy VPNs and perimeter-based access models are a poor fit for that requirement because they hide too much, trust too broadly and make evidence collection difficult. The article’s core point is that compliance now depends on how access is granted, observed and revoked in operation, not just on policy language.

For financial institutions and third-party ICT providers, this means identity controls, session visibility and deprovisioning discipline are now part of resilience reporting. The challenge is not only controlling access, but proving that the control works every time it is used.

Key questions

Q: What breaks when third-party access is managed with legacy VPN and perimeter models under DORA?

A: 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.

Q: Why does DORA make access governance a resilience issue?

A: DORA ties operational resilience to the ability to withstand, respond to, and recover from ICT disruptions. Access governance sits at the centre of that because compromised or poorly managed identities determine how far an incident spreads and how quickly it can be contained. If you cannot answer who had access, resilience claims are weak.

Q: How can teams tell whether their access controls are actually DORA-ready?

A: A DORA-ready access control set should answer who accessed what, when and why, while also showing that the session was segmented, monitored and revocable. If the evidence depends on network logs alone, the control is probably too coarse. The test is whether compliance teams can reconstruct and explain each third-party access decision.

Q: Who is accountable when third party privileged access is not governed properly under DORA?

A: Accountability sits with the organisation that grants and oversees access, even when contractors, partners, or service providers are involved. DORA expects firms to control third party risk, log privileged activity, and maintain evidence for reporting and review. Delegating access does not delegate responsibility for governance, monitoring, or regulatory outcome.

Technical breakdown

Why legacy VPN access breaks under DORA

Legacy VPNs extend trust after authentication, which is the opposite of what DORA expects in a regulated environment. Once a user is inside the network, broad reachability, weak segmentation and limited session-level context make it hard to prove that access was narrowly scoped. DORA’s emphasis on auditability and continuous verification makes that model fragile because access evidence becomes indirect and often incomplete. In practice, a perimeter is not the same thing as an access control decision.

Practical implication: replace network-centric trust with identity- and session-scoped access controls that can be evidenced continuously.

Third-party access as a regulated identity lifecycle problem

The article treats vendors, contractors and service providers as a specific governance problem, not just an external user class. That matters because third-party access has a lifecycle: approval, provisioning, monitoring, and revocation. Under DORA, each stage needs traceability and segmentation, otherwise organizations cannot demonstrate that external access is limited to authorised systems and data. Misconfigured permissions and weak offboarding are not just operational issues here, they become compliance failures.

Practical implication: govern third-party access with the same lifecycle discipline used for internal identities, including rapid deprovisioning when risk changes.

Why real-time verification matters for auditability

DORA does not simply ask whether access was allowed once. It expects institutions to prove who accessed what, when and why, with continuous monitoring and logs that support investigation and compliance review. That shifts the technical burden toward attribute-based policy, session metadata and audit trails that can be correlated with identity, device trust and risk state. The governance question is whether access decisions are reproducible after the fact, not just whether they were technically successful at the time.

Practical implication: build access controls that emit usable evidence for every session, not just periodic compliance reports.

NHI Mgmt Group analysis

Legacy perimeter access is now a governance liability, not a convenience layer. DORA turns access control into a proof problem, and proof is exactly what broad VPN-style trust makes difficult. When every external session must be segmented, monitored and attributable, network reachability stops being a useful proxy for authorised access. The practitioner conclusion is that legacy perimeter models no longer satisfy regulated access governance.

Third-party access is the most visible fault line in DORA programmes. The regulation explicitly forces institutions to account for vendors, contractors and service providers as part of the control surface. That expands identity governance beyond employee accounts and into external lifecycle management, where approvals, monitoring and offboarding often sit outside the core IAM programme. The practitioner conclusion is that third-party access must be governed as a first-class identity population.

Continuous verification is the new minimum evidence standard. DORA demands more than policy intent or annual review. It expects organisations to demonstrate that access decisions are granular, traceable and enforceable across cloud, on-prem and hybrid environments. That raises the bar for audit readiness because static entitlements alone do not prove operational resilience. The practitioner conclusion is that evidence generation must be designed into the access path itself.

Identity blast radius becomes the relevant control metric. DORA does not care whether a team has a large access stack; it cares whether a compromised vendor session can move farther than it should. Segment-of-one thinking reduces that blast radius by constraining each request to the minimum reachable surface. The practitioner conclusion is that segmentation quality, not perimeter size, is what determines resilience under regulatory scrutiny.

What DORA validates is the shift from access administration to access assurance. The market signal here is broader than one regulation. Financial institutions now need controls that can show, in real time, that access is contextual, revocable and observable. That pushes identity programmes toward runtime governance rather than after-the-fact review. The practitioner conclusion is to measure access by assurance quality, not by provisioning speed alone.

What this signals

Identity blast radius is the right way to think about DORA-era access. If a third party can move laterally after initial access, the control failed before the audit began. Financial institutions should measure how far any external identity can travel, not just whether it authenticated successfully.

DORA also exposes a programme design gap: many access teams still separate provisioning, logging and revocation into different workflows. That separation makes it difficult to prove continuous control, especially when external risk changes quickly. The practical response is to unify those workflows into one governed access lifecycle.

For practitioners

• Map third-party access paths Inventory every vendor, contractor and service-provider pathway into production systems, then classify which sessions require stronger segmentation, monitoring and revocation authority.
• Replace perimeter trust with contextual access decisions Use identity, device posture, location and risk signals to make each access request specific to the session instead of assuming network location implies trust.
• Instrument every external session for audit evidence Capture who accessed what, when and why, and retain session metadata that compliance teams can correlate with policy decisions and incident response.
• Automate third-party deprovisioning triggers Tie access removal to vendor risk changes, contract end dates and breach signals so external accounts do not remain active after their business need ends.
• Test segmentation against a compromised supplier scenario Validate that a single external identity cannot traverse from its intended target system into adjacent financial data or administrative zones.

Key takeaways

• DORA reframes third-party access as a regulated resilience problem, not a convenience issue.
• Legacy VPN and perimeter controls struggle because they do not prove session-level segmentation or revocation.
• Financial institutions need identity-based access assurance that can be monitored, evidenced and withdrawn continuously.

Key terms

• Third-Party Access Governance: Third-party access governance is the control set that tracks, approves, reviews, and revokes access granted to external vendors and partners. It becomes an identity problem when suppliers operate through shared credentials, delegated workflows, or persistent machine access that outlives the business need.
• Segment-of-One Access: A Zero Trust access pattern in which each session is scoped to one user, device, and resource relationship at a time. It is designed to remove lateral movement opportunities by preventing broad network reach after authentication. For non-human and autonomous contexts, it limits what a compromised identity can touch during execution.
• Continuous Verification: A Zero Trust practice that re-evaluates trust during the session instead of relying on a single successful login. The control is stronger when context signals are available in real time and when the identity programme can act on those signals without creating excessive exceptions.
• Runtime auditability: Runtime auditability is the ability to reconstruct who or what acted, what policy allowed it, and what data or tools were used while the system was operating. For autonomous agents, it is essential because retrospective logs without authority context rarely satisfy governance or regulatory review.

Deepen your knowledge

Identity lifecycle management, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.