Notifications
Clear all
Topic starter
11/07/2026 8:34 pm
TL;DR: DORA now requires financial entities to prove secure, traceable, continuously monitored third-party access across complex environments, and Appgate argues legacy VPN and perimeter models are not built for that level of accountability. The regulation turns access governance into an operational resilience problem, not just an audit exercise.
NHIMG editorial — based on content published by Appgate: DORA, third-party access, and Zero Trust Network Access
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Replace broad VPN reach with segmented access paths Limit external users to only the applications and administrative functions they explicitly need.
- 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.
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
👉 Read Appgate's analysis of DORA, third-party access, and ZTNA →
DORA and third-party access: what IAM teams need to change?
Explore further
11/07/2026 9:02 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: DORA exposes the limits of legacy access models
