
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):
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.
As of 2026, five DORA articles create direct implications for how organizations handle privileged credentials.
The table we made below summarizes them.
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.
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:
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.
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.
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.
Our Blog