Because delegated access often persists longer than the business need that created it, especially across vendors, managed services, and temporary integrations. If keys, tokens, or service accounts are not revoked promptly, they expand the attack surface and weaken incident containment. Under DORA, that becomes both an operational and a governance problem.
Why Third-Party Credentials Create DORA Compliance Risk
Third-party credentials turn a supplier relationship into a live security dependency. Under DORA, that matters because operational resilience is not just about keeping services running, but about proving that access, oversight, and recovery remain under control when vendors, MSPs, or integrators are involved. Long-lived keys, shared service accounts, and stale tokens make it harder to evidence least privilege, timely revocation, and incident containment. The risk is especially visible in secret sprawl cases like the Guide to the Secret Sprawl Challenge, where access persists beyond the business purpose that created it.
DORA-aligned governance expects institutions to understand who has access, why that access exists, and how quickly it can be withdrawn. That is difficult when third parties operate across cloud consoles, CI/CD pipelines, support channels, and temporary integrations. Current guidance suggests the problem is not merely vendor trust, but the inability to continuously demonstrate control over delegated access. The DORA text and the NIST Cybersecurity Framework 2.0 both reinforce the need for traceability and timely corrective action. In practice, many security teams encounter third-party access risk only after an audit, a breach, or a failed offboarding event, rather than through intentional vendor lifecycle control.
How It Works in Practice
The compliance issue usually starts with convenience. A supplier needs access for implementation, monitoring, support, or automation, so a credential is issued with broad scope and no clear end date. Over time, that access gets reused for troubleshooting, extended across environments, or copied into scripts and integrations. For DORA, that creates a governance gap: the institution may know the vendor exists, but not whether each credential is still justified, segregated, and revocable on demand.
Best practice is to treat third-party access as a time-bound control, not a standing entitlement. That means recording the business purpose, owner, scope, expiration, and revocation path for each credential. It also means preferring short-lived secrets, federated identity, and workload-specific authentication over permanent shared keys. The OWASP Non-Human Identity Top 10 is useful here because many third-party risks are really NHI risks: credentials outlive the human contract, the support ticket, or the integration they were created for.
Operationally, teams should map third-party credentials to assets and controls, then test whether they can be revoked quickly during an incident. This should include cloud access, API tokens, CI/CD secrets, remote support accounts, and service identities used by managed providers. The most relevant NHIMG guidance is the Ultimate Guide to NHIs — Regulatory and Audit Perspectives alongside the 52 NHI Breaches Analysis, both of which show how ungoverned non-human access becomes an audit and incident-response problem. These controls tend to break down when third parties maintain persistent integrations across multiple environments because revocation then requires cross-system coordination instead of a single administrative action.
- Issue credentials per task or per environment, not as a universal vendor login.
- Set explicit TTLs and automate revocation when work ends or contracts change.
- Track ownership and purpose so every third-party credential has a named accountable controller.
- Log and review vendor use of privileged paths, especially admin consoles and secrets stores.
Common Variations and Edge Cases
Tighter third-party access control often increases operational overhead, requiring organisations to balance resilience against vendor friction and support latency. That tradeoff is real, especially where legacy tooling cannot support federation, short-lived tokens, or granular delegated permissions. In those environments, the guidance is evolving rather than universal: some institutions still use compensating controls, but current practice increasingly favours replacing static secrets rather than trying to govern them indefinitely.
Edge cases include emergency support access, managed detection and response tooling, and contractors who need intermittent administrative reach. These scenarios are high risk because they encourage standing credentials “just in case.” DORA-focused programs should require explicit approvals, narrow scope, and rapid expiry even for exception paths. The Top 10 NHI Issues and Ultimate Guide to NHIs — Static vs Dynamic Secrets are directly relevant because they show why dynamic secrets reduce both compromise window and audit burden.
Where organisations struggle most is in multi-vendor chains, where one provider’s token grants access to another provider’s platform or shared tooling. That creates a revocation dependency that can outlast the original contract. The DORA — Digital Operational Resilience Act framework treats that as a resilience issue, not just an IAM issue, because a delayed deprovisioning event can become an operational outage. In practice, this guidance breaks down when third parties control the only administrative path to the service, because validation and emergency cutover then depend on the very party being de-risked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Third-party secrets and stale access are core NHI governance risks. |
| NIST CSF 2.0 | PR.AC-4 | Vendor access must be limited, reviewed, and removed when no longer needed. |
| NIST AI RMF | DORA risk increases when autonomous or automated third-party access lacks governance. |
Inventory vendor-issued NHIs, set TTLs, and revoke any credential that lacks a current business purpose.
