Why do privileged and third-party accounts matter so much in DORA programmes?

Why privileged and third-party accounts carry outsized weight in DORA programmes

Privileged and third-party access sit at the point where resilience can fail fastest: one can change systems at speed, the other can persist longer than the business need that justified it. In DORA programmes, that makes both account classes more than an IAM housekeeping issue. They are operational-risk controls because they shape how quickly a financial entity can absorb, contain, and recover from disruption.

For privileged users and privileged service paths, the concern is blast radius. If an account can alter configuration, reset credentials, or bypass normal workflows, any compromise or misuse can become systemic. For third-party accounts, the concern is dependency and control loss. Access that is granted for support, integration, or outsourcing often spans multiple teams and systems, so it can become hard to see, hard to narrow, and hard to revoke when the relationship ends.

That is why DORA programmes treat these identities as resilience-sensitive: the question is not only who is authorised today, but whether the organisation can still prove control after a vendor change, a staffing change, or a security incident. A useful way to think about the issue is that privilege creates impact potential, while third-party access creates persistence risk and accountability gaps.

What makes these accounts different from ordinary access

Ordinary user accounts usually have a narrow business purpose and a short path to remediation when something goes wrong. Privileged accounts and external-access accounts are different because they sit closer to critical systems, critical data, and recovery processes. That proximity matters in resilience programmes because an outage, compromise, or misconfiguration involving these accounts tends to affect more than one control objective at once.

Privileged accounts matter because they can override guardrails. They often control configuration, incident response, backup, logging, access reviews, or environment administration. If those accounts are excessive, shared, or poorly monitored, the organisation may not just have an access problem, it may have a recovery problem. DORA’s resilience emphasis makes that distinction important: strong controls are needed before a disruptive event, not improvised after one.

Third-party accounts matter because the organisation does not fully own the operating conditions around them. A supplier may change staff, tooling, authentication methods, or support processes without the financial entity seeing those changes immediately. That creates a gap between nominal approval and actual assurance. The result is often a control that looks current on paper but no longer reflects the real access path.

Why DORA programmes need continuous oversight, not one-time approval

DORA pushes teams away from static approvals because resilience depends on current truth, not historical permission. If a privileged role remains standing after its task is complete, or if a vendor account stays active after a contract or integration change, the organisation inherits unnecessary exposure. That exposure is especially important in operational resilience programmes because dormant or overbroad access can survive long after the original project, incident, or onboarding event has faded from view.

The practical implication is that access review must be tied to operational context. Teams should know what the account is for, who owns it, when it was last used, what systems it can reach, and what event will trigger removal or step-up review. For third-party access, that also means checking whether the access path is still needed for support, whether it is time-bound, and whether the supplier’s own controls still match the organisation’s tolerance.

DORA-aligned programmes also need evidence that oversight is real. A monthly recertification that never leads to removal is weaker than a smaller, well-owned review that actually reduces standing access. Likewise, a privileged account that is technically “approved” but not session-monitored or separately inventoried is often a resilience gap hiding inside a compliance control.

Risk and Threat Considerations

Privileged and third-party accounts are attractive because they compress the path from access to impact. If an attacker steals privileged credentials or abuses a supplier path, the result can be rapid system manipulation, data access, or disruption across multiple services. The risk is not limited to breach exposure, it extends to recovery failure, because the same access path that enabled the attack may also undermine containment and restoration.

Failure mechanism: Excessive privilege, long-lived supplier access, weak visibility, and delayed revocation let legitimate-looking accounts outlive their purpose or be used for high-impact actions without timely challenge.

Impact: A financial entity can lose control over critical systems, incident response can be slowed, and operational disruption can spread beyond the original account or supplier relationship.

Practitioner Guidance

What to prioritise: Start with the accounts that can change production state, approve access, reset credentials, or reach business-critical workflows. For third-party access, prioritise anything tied to support, remote administration, integrations, or outsourced operations, because those paths often combine high privilege with weak day-to-day visibility. Privileged Access Management Guide is useful here because it frames privileged control as a lifecycle problem, not just a login problem.

What to verify: Confirm that every privileged or external account has a named owner, a current business purpose, an expiry or review trigger, and a tested removal path. For third parties, verify that access is tied to an active contractual or operational need, not just a legacy integration. If the answer cannot be produced quickly during an audit or incident, the control is probably weaker than the approval record suggests.

What good looks like: The best operating state is narrowly scoped access, short-lived elevation where possible, frequent review of actual use, and fast revocation when need ends. That standard is especially important for external identities because their risk profile changes whenever the supplier, support model, or integration pattern changes. Third-Party, B2B and Contractor Access Guide is a strong companion for that governance model.

Practitioner takeaway: In DORA programmes, privileged and third-party accounts should be treated as resilience controls with a privilege lifecycle, not as routine access records. If you can’t prove who owns them, why they still exist, and how fast they can be removed, you do not really control the operational risk they create.

Related resources from NHI Mgmt Group

• Why do privileged accounts matter so much in data posture programmes?
• Why does third-party risk matter so much in GRC programmes?
• Why do privileged accounts matter so much in MaRisk and DORA reviews?
• Why do privileged accounts matter so much in NHI risk management?