Mapping DORA Compliant Access Management to PAM.

February 18, 2026
|
Read Time:
8 minutes

Full Digital Operational Resilience Act (DORA) compliance is still a work in progress for almost every FSI firm. At the end of 2025, only 18% of security teams considered themselves to be fully ready for DORA.

As with many newer financial regulations, such as NIS2, breaking down DORA's compliance requirements into a clear process and technology recommendations can be confusing, to say the least.

SplitSecure provides a privileged access management solution built around DORA's requirements. Learn More.

However, when we look at DORA’s requirements for how access to sensitive data and systems is supposed to be controlled and audited, we can say that the regulator effectively mandates two capabilities related to privileged access management (PAM):

  1. Your organization must use an access and secrets management solution capable of granular access control that leaves a clear audit trail.
  2. Whatever solutions you use should ideally not share secrets with external cloud providers and increase your third-party risk.

In this article, we cover the specific DORA articles that call for PAM or secrets management tools, share a mapping framework to evaluate whether a solution is DORA-compliant, and make the case for using a distributed secrets management approach.

DORA Has 5 Access Management-Related Articles That Mandate PAM Capabilities

As of 2026, five DORA articles create direct implications for how organizations handle privileged credentials.

The table we made below summarizes them.

DORA Requirement Article What Privileged Access Management Needs To Do
Access control policies Article 9(4)(c) Privileged access must be controlled and auditable
ICT third-party concentration risk Article 28(4)(c) / Article 29 Critical functions should not be over-dependent on external vendors
Exit strategies for ICT services Article 28(8) Firms must be able to exit vendor relationships without service disruption
Data protection and confidentiality Article 9(3)(b) Sensitive data must be protected in transit and at rest
Audit trails and logging Article 12 Access to critical systems must be logged and reviewable

As you can see from the above, DORA’s compliance mapping and privileged access management requirements appear throughout the DORA regulation, but are most explicitly called out in Article 9.

DORA Article 9 Access Control and Audit Requirements Explained

Article 9 of DORA establishes requirements for ICT security policies that explicitly include access control mechanisms.

Financial institutions must implement policies governing access to ICT assets and ensure that access rights are assigned in accordance with the principles of need-to-know, least privilege, and separation of duties.

For teams responsible for privileged access management, this means three things:

  1. Users should only have access to the credentials they need for their specific role. Traditional PAM solutions address this through role-based access controls, but implementation complexity often leads to overly permissive configurations.
  1. No single person should be able to complete a critical transaction alone. For secrets management, this means that accessing the most sensitive credentials should require multiple parties.
  1. Access to critical systems must be logged, and those logs must be protected from tampering. For privileged access, this means every credential retrieval should generate an auditable record.

Traditional PAM Solutions Fall Short of Full DORA Compliance

Traditional privileged access management solutions (deployed either on-premises or SaaS) can technically meet some of the above requirements, but were designed before DORA's third-party risk requirements existed.

On-premise deployments require significant infrastructure investment, ongoing maintenance, and dedicated expertise, with implementation projects often spanning months.

The financial industry compliance teams we talk to often report that the gap between purchasing a PAM solution and achieving full operational deployment substantially exceeds initial estimates. Almost one in two IT leaders describes PAM implementation complexity as a top challenge.

The alternative many organizations turn to is cloud-based SaaS platforms that eliminate infrastructure overhead but introduce the third-party dependency that DORA Article 28 (see table above) specifically addresses (i.e., your secret retrieval depends on the vendor's platform availability).

Neither model of privileged access management is inherently wrong.

But for their highest-sensitivity credentials, organizations subject to DORA may need an approach that does not add to their third-party dependency while avoiding the operational complexity of self-hosted infrastructure.

SplitSecure provides DORA-compliant access management by default. Learn More.

DORA Privileged Access Management Compliance By Default

The easiest way to meet any regulation is to be architecturally compliant. That is to have systems in place so compliance does not need to be enforced by policy or process, but rather occurs as a technological default.

In practice, this means routine operations are DORA-compliant without anyone having to double-check.

SplitSecure gives you exactly that.

We developed a secrets management approach specifically for regulatory frameworks like DORA that ask for access management without third-party dependency.

Credentials are never seen by SplitSecure, and instead, fragments are distributed across devices you control. This means that a breach of SplitSecure does not expose your credentials. And if SplitSecure ceased operations, your deployments would still function.

As a result, SplitSecure directly addresses concentration risk requirements in DORA Article 28.

Article 9 DORA requirements (separation of duties) are met by SplitSecure architecturally.

With SplitSecure, reconstructing a secret requires a threshold of devices. This is not a policy that can be bypassed through social engineering or emergency exceptions, but is a mathematical property of how SplitSecure works.

DORA-ready audit trails are also created automatically. Every secret reconstruction generates a record because the distributed architecture requires coordination across devices. With SplitSecure, you cannot access a credential without creating an audit trail, thereby meeting the logging requirements in DORA Article 12 by default.  

For most real-world compliance teams, another core benefit is minimal (or zero, depending on configuration) infrastructure to maintain.

Unlike on-premises PAM solutions, SplitSecure does not require vault servers, cluster management, or dedicated engineering resources. The operational footprint is minimal, reducing the implementation complexity that often delays PAM deployments.

DORA Compliant Assessment Management Made Simple

See how SplitSecure helps financial institutions meet DORA's requirements for access control, audit trails, and third-party risk management.

Learn more about a simple to deploy and use PAM solution that makes sure distributed secrets are never seen by third parties and separation of duties is enforced by architecture without increasing your vendor dependency.

Tristan Morris
CEO, Co-Founder @ SplitSecure
A prodigy who started attending college at age 12. After graduating from Cornell with a degree in Aerospace Engineering, Tristan went on to lead product for Federal Security at KNOX, Samsung’s military and defense cybersecurity group.
LinkedIn
Share this post

Check out our Whitepaper on

The Next Generation of Enterprise Security

Download WhitePaper

Ready to see SplitSecure in action?

No jargon. No friction. Just stronger security for your organization.
Book a Demo