Because outsourced access often combines elevated privilege with weaker lifecycle control. If supplier identities, remote support sessions, or service credentials stay active after the need ends, the financial institution inherits both operational and regulatory exposure. DORA pushes teams to govern who can access production, for how long, and under what traceability.
Why This Matters for Security Teams
Third-party access paths are risky because they sit at the intersection of privilege, remote connectivity, and accountability. Under DORA — Digital Operational Resilience Act, financial entities must be able to show that outsourced access is controlled, monitored, and removable when no longer required. The concern is not only who logged in, but whether the access path itself can be trusted across onboarding, use, review, and offboarding.
Security teams often focus on the vendor contract or the initial approval, then assume the risk is covered. In practice, the exposure usually comes from the operational details: shared service accounts, standing privileged access, forgotten remote support tools, and temporary exceptions that become permanent. Those gaps weaken traceability and make incident response harder, especially when the activity occurs through a supplier-controlled channel rather than a corporate identity.
Current guidance suggests treating third-party access as a governed identity pathway, not a one-time permission grant. That means linking the supplier, the human operator, the service account, the session, and the business justification. Without that chain, audit evidence becomes fragmented and control ownership becomes ambiguous. In practice, many security teams encounter DORA problems only after a supplier session has already been used in production without clear evidence of approval, review, or revocation.
How It Works in Practice
Managing third-party access well requires more than periodic vendor reviews. It needs control over identity issuance, privilege scope, session supervision, and lifecycle termination. The most effective programs map each external access route to a named owner, a specific business purpose, and a defined expiry condition. That applies to human vendor users, remote support operators, and non-human credentials such as API keys or service tokens, which are often overlooked even though they create the same operational exposure.
A practical model usually includes:
- pre-approved access pathways with explicit business justification and time limits
- strong authentication for supplier identities, with no reliance on shared accounts where avoidable
- session recording or equivalent oversight for elevated support activity
- least privilege aligned to the narrowest task the supplier must perform
- automated revocation for expired, unused, or contract-ended access
This maps closely to the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access enforcement, auditability, and separation of duties, and it complements the operational posture described in the NIST Cybersecurity Framework 2.0. Where organisations use service identities or automated support tooling, the OWASP Non-Human Identity Top 10 is especially useful for spotting where machine credentials outlive their purpose or escape inventory control.
These controls tend to break down when supplier access is delivered through shared jump hosts or legacy remote administration channels because individual accountability and session attribution become too weak to evidence reliably.
Common Variations and Edge Cases
Tighter third-party control often increases operational friction, requiring organisations to balance rapid supplier support against stronger approval, monitoring, and revocation steps. That tradeoff is real, especially when production incidents depend on external experts who need fast access.
Not every third-party path carries the same DORA risk. A low-privilege SaaS support login is not equivalent to a production database administrator account, and best practice is evolving on how much evidence is enough for each category. Current guidance suggests using risk-based segmentation rather than a single approval model for all suppliers. High-impact arrangements should receive stronger session control, more frequent access reviews, and tighter contract clauses than routine business applications.
Edge cases often appear where human and non-human access blur together. A vendor may authenticate as a person but operate through automation, or a managed service may use embedded credentials that no one reviews because they are treated as technical plumbing. That is where identity governance becomes a DORA issue, not just an IT hygiene issue. The key question is whether the institution can prove who or what accessed production, why it was allowed, and when it stopped.
In highly regulated environments, teams should also distinguish between access risk and resilience risk. If a supplier outage or credential failure can interrupt a critical service, the access path is part of operational resilience planning, not merely an IAM control. The practical test is simple: if the access cannot be rapidly traced, limited, and removed, it is not well governed enough for DORA expectations.
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 surface, NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the technical controls, and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Third-party access depends on least-privilege enforcement and access governance. |
| NIST AI RMF | Risk governance helps formalise accountability for supplier-controlled access paths. | |
| OWASP Non-Human Identity Top 10 | Service accounts and machine credentials are common third-party exposure points. | |
| DORA | DORA expects traceable, controlled, and removable third-party access to critical services. | |
| NIST SP 800-53 Rev 5 | AC-2 | Account lifecycle controls are central to governing supplier identities and accounts. |
Assign ownership for third-party access risk and document controls across the access lifecycle.
