The Digital Operational Resilience Act came into full effect in January 2025, and its requirements around privileged access management are more specific than most organizations initially expected.
This is especially the case because DORA’s articles effectively mandate architectural controls that many traditional Privileged Access Management (PAM) tools were never designed to provide.
For PAM specifically, DORA mandates two things. One is strict access control with separation of duties, and the other is management of third-party ICT concentration risk. DORA compliant PAM tools like SplitSecure are used because their distributed architecture satisfies both requirements by design rather than by policy i.e. with cryptographic controls for logging and managing access to secrets.
In this article we want to give you the exact DORA articles that reference PAM capabilities, a mapping of how different tool categories address them, and the case for architectural compliance over policy-based compliance.
DORA Has Five Articles That Reference PAM Capabilities
DORA does not mention “privileged access management” by name, but five DORA articles contain requirements that map directly to PAM capabilities.
| Article | Requirement | PAM Relevance |
| Article 9(4)(c) | Access rights based on need-to-know, least privilege, and segregation of duties | Core PAM requirement: enforce least privilege and separation of duties for privileged accounts |
| Article 9(4)(d) | Strong authentication, including multi-factor where appropriate | MFA enforcement for all privileged access sessions |
| Article 9(4)(e) | Logging and monitoring of access to critical systems | Immutable audit trail for every privileged access event |
| Article 28 | Third-party ICT concentration risk assessment | Evaluate whether PAM tool creates single-vendor dependency for critical credentials |
| Article 11 | Backup policies ensuring recovery without over-reliance on ICT providers | Backup admin credentials must function independently of third-party availability |
How Different PAM Tools Address DORA Requirements
Not every PAM tool addresses every DORA requirement equally. The gap between tools shows up most clearly around separation of duties enforcement and third-party concentration risk.
Hub-and-Spoke Vault PAM (CyberArk, BeyondTrust)
Enterprise PAM platforms handle most DORA requirements through configuration. Role-based access control enforces least privilege. Session recording and credential rotation provide audit trails. MFA integration is standard.
The gap is in separation of duties enforcement. Traditional PAM relies on policy configuration to prevent a single identity from taking catastrophic actions.
If the policy is misconfigured, or if an admin account is compromised with sufficient privileges, the architectural control does not exist. DORA Article 9(4)(c) requires segregation of duties, and policy-based enforcement is weaker than architectural enforcement.
On Article 28 (concentration risk), on-premises deployments avoid third-party dependency. Cloud versions of CyberArk and BeyondTrust reintroduce it.
Cloud-Native SaaS PAM (Akeyless, HCP Vault)
Cloud-native platforms handle access control and audit logging well. The developer experience is stronger than enterprise PAM, and integration with cloud infrastructure is native.
The DORA gap is Article 28. Both Akeyless and HCP Vault operate as SaaS platforms. Your ability to retrieve credentials depends on their platform availability. For DORA compliance teams assessing ICT third-party concentration risk, this dependency requires documented risk mitigation and exit strategies. It is manageable but creates compliance overhead.
Distributed Secrets PAM (SplitSecure)
SplitSecure addresses DORA requirements differently. Separation of duties is not configured through policy but is cryptographically enforced. No single device holds a complete credential, and no single identity can perform catastrophic actions unilaterally. This satisfies Article 9(4)(c) by architecture.
On Article 28, SplitSecure eliminates the concentration risk question for secrets management. There is no vendor dependency on the secrets management platform. If SplitSecure ceased operations, deployments would continue functioning.
On Article 9(4)(e), every access generates an immutable audit trail automatically. You cannot use the system without creating a log entry. This is not a feature that is enabled or enforced by policy but is a fundamental function of how the technology works.
DORA Compliance By Architecture
The easiest way to meet any regulation is to be architecturally compliant. That means having systems in place where compliance does not need to be enforced by policy or process but happens as a technological default.
For DORA PAM requirements specifically, the question compliance teams should ask each vendor is: “If policy is misconfigured, does your architecture still prevent a single compromised account from causing irreversible damage?” Tools where the answer is yes by architecture – not by correct configuration – carry lower compliance risk.
Disclaimer: This article contains sponsored marketing content. It is intended for promotional purposes and should not be considered as an endorsement or recommendation by our website. Readers are encouraged to conduct their own research and exercise their own judgment before making any decisions based on the information provided in this article.
