DORA exposes the limits of legacy access models

At a glance

What this is: This is an analysis of how DORA reshapes access governance for financial institutions, with third-party access, auditability, and continuous verification at the centre.

Why it matters: It matters because IAM, PAM, and NHI teams supporting regulated financial environments must prove access control, session traceability, and revocation readiness across internal and external identities.

👉 Read Appgate's analysis of DORA, third-party access, and ZTNA

Context

DORA raises the bar for access governance by treating secure, traceable access as part of operational resilience, not a separate compliance task. For financial institutions operating across cloud, on-premises, and third-party environments, the core problem is proving that every access decision is explicit, segmented, and reviewable.

The access model that worked for perimeter-era networks does not map cleanly to DORA's demands for continuous verification, audit trails, and rapid revocation. That gap becomes sharper when external vendors and contractors are part of the access chain, because accountability must extend beyond the organisation's own directory.

Key questions

Q: How should security teams govern third-party access under DORA?

A: They should treat third-party access as a regulated identity path, not an exception. That means explicit entitlement scope, named internal ownership, session logging, rapid revocation, and evidence that access remains justified throughout the vendor relationship. If an external user can reach systems without a clear owner and revocation trail, the control is not DORA-ready.

Q: Why do legacy VPN models fall short for DORA compliance?

A: Legacy VPNs often assume network location equals trust, but DORA requires continuous proof of who accessed what, when, and under which approval. A tunnel may connect a user, but it does not by itself prove segmentation, least privilege, or revocation readiness. Regulated access needs identity-centric controls that can be audited session by session.

Q: What breaks when third-party access is not segmented and logged?

A: The organisation loses the ability to show that external users only touched the systems they were authorised to use. Without segmentation and logs, investigators cannot reconstruct session scope, compliance teams cannot validate control enforcement, and risk teams cannot quickly contain a vendor-related issue. That creates both audit exposure and operational blind spots.

Q: Who is accountable when external access stays active after a vendor relationship changes?

A: Accountability sits with the internal owner of the access path, not the vendor. Financial institutions need a clear control owner for offboarding, revocation, and evidence retention so access does not outlive the business need. Under DORA, an expired relationship with live access is a governance failure, not a clerical oversight.

Technical breakdown

Why perimeter-based access models struggle under DORA

Perimeter security assumes trust can be established once a user or system crosses the network boundary. DORA pushes in the opposite direction: access must be justified continuously, with identity, device posture, and policy all considered at decision time. That makes static network trust and broad VPN reach hard to defend, especially when sessions span multiple environments and administrative domains.

Practical implication: move regulated access paths toward continuously evaluated controls rather than relying on network location as a trust signal.

Third-party access as an auditability and segmentation problem

Third-party access is not just a vendor-management issue. Under DORA, it becomes a control problem involving segmentation, logging, and proof that external users only reach explicitly authorised systems and data. If external sessions are not individually attributable and reviewable, institutions cannot demonstrate that the access boundary is being enforced in practice.

Practical implication: require session-level evidence, role scoping, and explicit entitlement boundaries for every external identity path.

Automated provisioning and deprovisioning as resilience controls

DORA's access expectations depend on speed as much as correctness. Manual granting and revocation create delay, inconsistency, and gaps when vendor risk changes or incidents occur. Automated lifecycle workflows reduce the time an external entitlement remains valid after the business need has changed, which is essential when regulators expect immediate control changes to be possible.

Practical implication: tie vendor onboarding, access updates, and offboarding to automated workflow controls with clear approval and revocation evidence.

NHI Mgmt Group analysis

DORA turns third-party access from a convenience layer into a governed identity boundary. The regulation makes external access part of the institution's resilience posture, which means contractors, vendors, and service providers can no longer sit outside the main access governance model. Auditability, segmentation, and revocation readiness now define whether third-party access is compliant. Practitioners should treat external identities as first-class governed subjects, not exceptions.

Legacy VPN trust assumptions were designed for network-centric control, not continuous accountability. That assumption fails when access must be attributable, segmented, and reviewable at the session level across distributed environments. The implication is that financial institutions must rethink how they evidence access decisions, because network reach no longer proves control.

Third-party access without lifecycle offboarding is the control gap DORA is exposing. If vendor access persists after the business relationship changes, the organisation loses the ability to prove that privilege is still justified. That is not just an operational weakness, it is a governance failure that DORA makes visible. Practitioners should focus on access expiry, revocation evidence, and external identity ownership.

Continuous verification becomes the minimum viable operating model for regulated access. DORA's access expectations assume that trust is never static and that every session may need to be revalidated as conditions change. This aligns closely with ZTNA principles, but the real lesson is governance: continuous proof matters more than broad entitlement lists. Security teams should build access paths that can be verified in real time, not only reconstructed after the fact.

Access governance for financial entities now spans internal IAM, external contractor control, and resilience evidence in one chain. That convergence matters because compliance teams can no longer separate who has access from how that access is monitored and how quickly it can be withdrawn. The practical conclusion is that identity teams, PAM teams, and compliance owners need a shared operating model for regulated access.

From our research:

• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to the State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• For a broader governance lens, see Ultimate Guide to NHIs , Regulatory and Audit Perspectives.

What this signals

Third-party visibility gaps are already large enough to undermine regulated access evidence. When 85% of organisations lack full visibility into OAuth-connected vendors, the issue is not just shadow access, it is a governance blind spot that makes DORA-style proof harder to produce. For regulated programmes, the priority is evidence-bearing access paths, not just more authentication steps.

DORA will push identity teams to unify contractor access, privileged access, and session monitoring around the same operating model. The institutions that do this well will be the ones that can answer a basic question quickly: which external identities are active, why, and who can remove them right now?

For practitioners

• Map every third-party access path to a named business owner Document which vendor, contractor, or service provider is granted access, why the access exists, and which systems or data are in scope. Require a named internal owner for review and revocation, not just an IT approver.
• Replace broad VPN reach with segmented access paths Limit external users to only the applications and administrative functions they explicitly need. Use segmentation to make protected systems unreachable outside approved workflows, then retain session logs that prove those boundaries were enforced.
• Automate external identity lifecycle controls Trigger provisioning, access changes, and deprovisioning from the same governed workflow that tracks contract status, risk posture, and approval state. Build revocation into the process so access can be withdrawn immediately when risk changes.
• Align audit evidence with access decisions Ensure logs capture who requested access, who approved it, when it was used, and when it was removed. Preserve the evidence in a form that compliance teams can reuse for DORA reporting and internal control testing.

Key takeaways

• DORA reframes third-party access as a resilience and accountability problem, not a network convenience problem.
• The biggest exposure is not only access breadth, but the inability to prove segmentation, ownership, and revocation at session level.
• Financial institutions need identity-centric controls that can evidence and withdraw external access continuously, not only during audits.

Key terms

• Third-party access: Access granted to vendors, contractors, and service providers outside the organisation's primary workforce. In regulated environments, it must be scoped, monitored, and revocable with the same discipline as internal access because the accountability for misuse still sits with the institution.
• Continuous verification: A control approach that evaluates access in real time rather than trusting a session once it starts. For regulated access, this means identity, device posture, and policy conditions are checked during the session so the organisation can prove trust is still warranted.
• Access segmentation: The practice of limiting a user or system to only the specific resources required for a task. In DORA-aligned environments, segmentation is what makes third-party access auditable, containable, and easier to revoke without affecting unrelated systems.

What's in the full article

Appgate's full analysis covers the operational detail this post intentionally leaves for the source:

• How Appgate maps ZTNA features to DORA's access-control and auditability expectations
• The specific session logging and centralized visibility mechanisms described for compliance teams
• How Appgate frames automated provisioning and deprovisioning in regulated financial environments
• The vendor's implementation-oriented discussion of segment-of-one access for third parties

👉 Appgate's full post covers the access-control model, compliance framing, and ZTNA implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.