Legislation · 12 Feb 2025 · Rob Nidschelm

DORA and Privileged Access: Why Admin Credentials Are a Resilience Issue

DORA is usually discussed in terms of risk frameworks, incident reporting and resilience testing. Those subjects matter, but many real attacks still succeed through something much simpler: an identity with more access than it should have.

An administrator account is designed to bypass ordinary restrictions. It can change configuration, create users, disable controls, read sensitive information and affect large parts of the environment. That authority is necessary for operations, but it also gives an attacker the shortest route from initial access to material disruption.

This is why privileged access management is closely connected to operational resilience. A financial entity cannot credibly claim that a critical service is protected if it cannot answer who can administer it, how that access is granted, how it is monitored and how quickly it can be removed.

DORA and its supporting technical standards make those expectations concrete. Access rights must be managed on need-to-know, need-to-use and least-privilege principles. Privileged, emergency and administrator access must be controlled. Strong authentication, user accountability, access review and timely revocation all form part of the picture.

Buying a PAM platform can help. It is not the same as building a working privileged-access control system.

Why privileged access creates disproportionate risk

Most user accounts can affect a limited set of data and functions. Privileged identities are different. They can influence the controls that are supposed to protect everyone else.

Attackers seek privileged access because it allows them to:

• disable endpoint or monitoring tools;
• create persistent accounts;
• extract credentials and move laterally;
• access backup infrastructure;
• alter logs or security configuration;
• deploy malware across many systems;
• interrupt services at scale;
• obtain sensitive or regulated data.

The identity may belong to a person, but it may also be a service account, application, automation pipeline, remote-support tool or third-party engineer. In many environments, non-human privileged identities are more numerous and less visible than administrator accounts assigned to employees.

The risk becomes greater when credentials are shared, permanently active or reused across systems. A single compromise can then become a platform for a much larger incident.

DORA changes the question from “Do we have PAM?”

The existence of a vault or privileged-access product is only one piece of evidence. The operational questions are more demanding.

• Are all privileged identities known?
• Are administrative tasks performed through dedicated accounts?
• Is access granted only when needed?
• Are sessions attributable to an individual or system?
• Is strong authentication applied to privileged and remote access?
• Are credentials rotated and protected from direct exposure?
• Are access rights reviewed often enough for the criticality of the system?
• Can emergency access be used without becoming an unmonitored back door?
• Can third-party access be disabled immediately?
• Are unusual privileged actions detected and investigated?

A control can fail even when the technology is present. Administrators may bypass it because the workflow is slow. Legacy systems may remain outside coverage. Emergency accounts may never be reviewed. Service accounts may have static passwords because nobody knows what will break if they change.

The objective is not product deployment. It is control over privileged authority.

Start with the critical service, not the account list

Many PAM projects begin by discovering accounts. That is necessary, but the account list does not show which identities could interrupt a critical business service.

A stronger approach starts with services covered by the organisation’s resilience framework. For each service, identify the applications, infrastructure, cloud subscriptions, network components, data stores, backup platforms and suppliers required to operate and recover it.

Then identify every privileged path into those components.

This often reveals access that traditional identity inventories miss: hypervisor consoles, local administrator accounts, database owners, break-glass users, domain-level groups, API keys, deployment secrets, service accounts and supplier portals.

The result should explain not only who has access, but what that access can do and what happens if it is misused.

The controls that matter most

Unique and attributable identities

Actions should be traceable to a specific person or system. Generic and shared administrator accounts weaken accountability because several people can appear as the same identity.

Where a shared technical account cannot be removed, access to it should be brokered through an attributable process. The organisation should be able to link the final privileged action to the user, approval and session that produced it.

Separate administrative accounts

Everyday productivity and privileged administration should not use the same identity. An administrator who reads email and browses the web through a highly privileged account increases the chance that a routine compromise becomes a critical one.

Dedicated accounts also make monitoring clearer. Administrative activity should be unusual enough to stand out.

Just-in-time and need-to-use access

Permanent privilege creates permanent exposure. Access that exists for two hours to complete an approved change presents less opportunity than access that remains active all year.

Just-in-time access can grant the minimum required role for a limited period and remove it automatically. This is particularly valuable for cloud platforms, where broad roles are often easy to assign and difficult to remember.

Strong authentication

Privileged access should not depend on a reusable password alone. Strong authentication reduces the value of stolen credentials, although it does not eliminate session theft, social engineering or abuse by an authorised user.

Authentication should also be resistant to the risk of the access path. Remote administration of a critical system deserves stronger controls than a low-impact internal function.

Session control and recording

High-risk sessions may need to be proxied, monitored or recorded. This improves deterrence, investigation and accountability. It can also support real-time intervention when a session behaves unexpectedly.

Recording should be designed carefully. Administrative sessions may expose secrets or personal data, so retention, access and privacy must be controlled.

Regular access review

Access decisions age quickly. People change roles, suppliers rotate staff, systems are replaced and projects end without permissions being removed.

The DORA technical standards require periodic review, with more frequent review for systems supporting critical or important functions. The strongest review is not a spreadsheet asking a manager whether a user still needs access. It shows the role, systems, last use, risk, owner and conflicts with other permissions.

Immediate revocation

Access should be removed when employment or a supplier relationship ends, or when it is no longer needed. “Immediate” is an operational capability, not a policy sentence.

The organisation should know which identity source controls the account, which systems are disconnected from central identity and who can act outside office hours.

Controlled emergency access

Break-glass access exists because ordinary controls may be unavailable during a crisis. That makes it essential for resilience and dangerous for security.

Emergency accounts should be protected, monitored and tested. Use should trigger an alert and a mandatory review. Credentials should change after use. The process should work when the normal identity platform is part of the outage.

Third-party administrators deserve the same scrutiny

Financial entities depend on ICT providers, and many suppliers require elevated access for support. Remote vendor access is therefore both an operational necessity and a common attack path.

Supplier access should be limited by system, time and task. It should use named identities, strong authentication and approved connection routes. Sessions involving critical systems should be monitored. Access should not remain open simply because a contract remains active.

Contractual commitments help, but the technical enforcement belongs in the financial entity’s control environment. If a supplier account can connect directly to a critical platform without the organisation seeing or restricting the session, the contract will not contain the incident.

PAM must include machines and automation

Traditional PAM programmes often focus on human administrators. Modern environments also contain pipelines, workloads, scripts, agents and applications with privileged credentials.

These identities may deploy infrastructure, read secrets, change firewall policy or administer cloud resources. They cannot complete an interactive approval in the same way a person can, so the control model is different.

Useful measures include workload identities, short-lived credentials, secrets managers, restricted API scopes, signed automation, environment separation and monitoring of machine actions. Static secrets embedded in source code or configuration are a direct conflict with controlled privileged access.

The same principle still applies: a machine should receive only the authority required for its function, and its actions should remain attributable.

Test the misuse scenario, not only the login

PAM testing often confirms that a user can request access and open a session. That proves the normal workflow, but not the resilience of the control.

More useful tests ask what happens when:

• an administrator’s endpoint is compromised;
• a privileged cloud token is stolen;
• a supplier tries to connect outside an approved window;
• a service-account credential appears in a code repository;
• the PAM platform itself is unavailable;
• an emergency account is used unexpectedly;
• an attacker attempts to disable backup or monitoring systems;
• an employee changes role but retains old access.

These scenarios connect identity control to incident detection, business continuity and recovery.

The evidence a regulator or auditor should be able to follow

For a critical system, the evidence chain should be simple enough to explain:

1. The system supports a defined critical or important function.
2. Privileged roles and accounts are identified.
3. Access is approved according to role and need.
4. Strong authentication and controlled connection methods are enforced.
5. Sessions and actions are logged with attributable identities.
6. Rights are reviewed on a risk-based schedule.
7. Unneeded access is revoked promptly.
8. Alerts and incidents produce investigation and remediation.
9. Emergency and recovery access is tested.

If the chain breaks, that is the gap to address.

Privilege is the ability to change the outcome

DORA is concerned with whether financial services can withstand and recover from ICT disruption. Privileged access sits at the centre of that question because privileged identities can change the systems, controls and evidence on which resilience depends.

The strongest PAM programme is therefore not the one with the largest vault. It is the one that makes privileged authority limited, temporary, attributable and observable across people, suppliers and machines.

When that authority is controlled, an attacker has fewer routes to turn one compromised identity into an operational crisis. That is not only access management. It is resilience engineering.

Sources and further reading

• Original Getronics article: Ask an Expert About DORA and PAM
• EUR-Lex: Regulation (EU) 2022/2554 (DORA)
• EUR-Lex: Delegated Regulation (EU) 2024/1774
• EBA: ICT and security risk management in the context of DORA

This article provides general technical and operational context, not legal advice.