Because third-party ICT providers can become part of the regulated entity’s operating surface. When a supplier holds privileged access, supports critical functions, or sits inside recovery processes, its security posture affects incident severity, continuity, and the firm’s ability to meet reporting and oversight obligations.
Why third-party access becomes a DORA compliance issue
DORA treats third-party access as part of operational resilience, not as a narrow vendor-management question. If an ICT supplier can authenticate, administer, support, or restore a critical service, then its access path can affect incident handling, service continuity, auditability, and reporting. That makes the supplier’s controls and the firm’s oversight inseparable from compliance.
For financial entities, the practical issue is not whether the third party is “trusted” in a general sense. The issue is whether that access can change the regulated entity’s ability to keep essential services running, contain an incident, and prove what happened. Once a supplier sits inside production support or recovery workflows, access governance becomes a DORA control concern.
DORA also forces firms to look past contract language and evaluate actual operating dependency. A vendor with elevated console access, remote support tooling, or privileged break-glass paths can widen the blast radius of a security failure. That is why access is assessed together with service criticality, logging, recovery dependencies, and exit readiness.
Where the compliance boundary moves from vendor management to regulated resilience
Third-party access matters most when it reaches privileged or operationally sensitive functions. That includes systems used to administer customer services, identity or support platforms, incident response tooling, backup and restoration processes, and any environment where the supplier can change availability, integrity, or confidentiality outcomes.
In practice, DORA cares about three things. First, whether the supplier can affect a critical or important function. Second, whether the firm can observe and control that access in time to respond. Third, whether the firm can recover if the supplier is unavailable, compromised, or exits unexpectedly.
The result is that access reviews, time limits, sponsorship, segregation of duties, and strong authentication are not just hygiene. They are part of proving that the firm can manage ICT risk across its supply chain and maintain operational resilience under stress.
For a useful practitioner contrast, the same access path can be acceptable in a low-impact support tool and high-risk in a recovery path. Under DORA, the question is not simply “does the supplier need access?” but “what regulated service depends on that access, and what happens if it is misused or fails?”
Why access oversight must cover lifecycle, logging, and exit
DORA risk does not end when access is granted. A third party can start as a limited support user and later accumulate broader permissions, dormant credentials, shared accounts, or persistent remote access. That drift is exactly what turns a manageable supplier relationship into a control weakness.
Firms should therefore treat third-party access as a lifecycle problem: approval, scope, monitoring, recertification, rotation, suspension, and removal. The same discipline applies when the supplier uses sub-processors or support chains, because the regulated entity still owns the outcome even if another company operates the account.
Exit planning is part of the compliance boundary too. If the firm cannot revoke access quickly, replace the function, or restore independently, then the dependency is already material. DORA expects evidence that access and recovery are not tightly coupled to one external party’s availability or goodwill.
Risk and Threat Considerations
Third-party access creates a compounded risk because attackers often target the weaker trust boundary rather than the best-defended internal system. If a supplier account, token, remote support path, or recovery channel is compromised, the attacker may inherit legitimate access that can bypass normal perimeter controls and accelerate incident impact.
Failure mechanism: Excessive or persistent supplier privileges, weak authentication, poor session control, or incomplete logging can let a vendor pathway become a privileged compromise path into critical services or recovery tooling.
Impact: The firm can lose availability, integrity, and audit confidence at the same time, which raises the likelihood of reportable incidents, failed recovery, regulatory scrutiny, and wider business disruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while DORA and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | Digital Operational Resilience Act | DORA directly governs ICT third-party risk and operational resilience for regulated financial firms. |
| Recommendation — Map third-party access to ICT risk controls, incident reporting, and resilience testing obligations. | ||
| NIST SP 800-53 Rev 5 | AC-20 — Use of External Information Systems | Third-party access is controlled through external system connections and supplier access paths. |
| IA-5 — Authenticator Management | Supplier access depends on credential lifecycle, rotation, and revocation discipline. | |
| AC-6 — Least Privilege | Vendor access becomes a compliance risk when suppliers hold broader rights than necessary. | |
| Recommendation — Restrict and monitor external access paths used by suppliers to reach regulated systems. Enforce lifecycle control for third-party credentials, secrets, and authenticators. Limit supplier permissions to the minimum needed for the supported function. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Third-party access is a supplier-relationship control issue requiring governance and oversight. |
| A.8.2 — Privileged access rights | Privileged supplier accounts materially shape the compliance and resilience risk discussed. | |
| Recommendation — Define supplier access obligations, oversight, and review requirements in the relationship. Review, restrict, and monitor privileged supplier access with stronger controls than standard access. | ||
Practitioner Guidance
What to verify: Confirm which third-party accounts can affect critical functions, which ones can reach recovery tooling, and whether every access path is individually owned, time-bound, and reviewable. If you cannot show that on demand, the control is not yet defensible.
Decision rule: If a supplier can change production state, recover data, or influence incident response, treat the access as high-impact and require stronger approval, monitoring, and offboarding than ordinary user access. If the vendor only has low-risk advisory access, the control burden can be lighter but still documented.
Practitioner takeaway: DORA makes third-party access a compliance issue because access is part of operational resilience, not just permissioning. The key judgment is whether the supplier’s access can alter your ability to keep services running, evidence incidents, and recover independently.