In 2026, Privileged Access Management (PAM) is a de facto compliance requirement for organizations ranging from small credit unions to multinational banks and fintechs.
Between DORA, NYDFS, PCI DSS 4.0, and evolving SOX interpretations, financial services firms are being asked to prove that their most sensitive credentials are protected, auditable, and not dependent on any single point of failure.
The regulatory trend for credential management lapses is increasingly severe:
Distributed privileged access management solutions like SplitSecure are architecturally built to meet current and future financial services compliance requirements by default.
Learn more about how SplitSecure supports compliance teams.
In the rest of this article, we draw on our experience developing an access management tool for the financial industry to provide the latest mapping between financial services regulations and PAM requirements.
Regulations that require credential management are a direct result of breaches that involve compromised credentials.
Some of the most damaging financial services breaches are not sophisticated zero-day attacks but credential compromises that proper PAM controls should have prevented.
The MOVEit breach in 2023 compromised over 60 banks through one vulnerability in a file transfer tool. Data tied to more than 96 million people across 2,773 organizations was stolen.
In 2025, Coinbase was breached when their third-party customer support contractors were bribed to use their credentialed access to retrieve and exfiltrate sensitive customer data, including government ID images, contact information, and account balance snapshots. The total cost was approximately $400m.
Each major regulation affecting financial services now includes requirements that map directly to privileged access management capabilities.
NYDFS is the most explicit. Section 500.7(c) requires Class A companies to implement a privileged access management solution by name.
DORA, PCI DSS 4.0, and SOX establish access control, audit trail, and separation-of-duties requirements that make PAM the practical answer.
In the table below, we break down where regulations call for PAM or PAM-like capabilities in 2026.
Across these regulations, there is a common call for financial services organizations to demonstrate (not just assert on paper) that their privileged access controls are technically enforced, independently auditable, and resilient to third-party compromise.
To meet the requirements outlined above, most financial services will use a PAM platform that falls into one of three categories.
On-premises PAM platforms like CyberArk and BeyondTrust offer deep feature sets, mature integrations with enterprise directories, and full control over where credentials are stored.
For organizations that already have the infrastructure and expertise, on-premises PAM provides the most granular control over session management, credential rotation, and access workflows.
But 44% of IT security teams point to complexity as a barrier to PAM adoption. On-premises PAM implementation projects can span months, and version upgrades can easily become multi-week projects. Troubleshooting requires deep platform expertise.
Financial services compliance teams often report that the gap between purchasing a PAM solution and achieving full operational deployment is substantially larger than initial estimates.
For teams with the resources to manage it, this is a proven model, but for financial services teams without dedicated PAM engineers, the complexity of on-premises PAM can be a liability in itself.
Cloud-based platforms like Akeyless and Delinea eliminate the need to run your own vault infrastructure.
Deployment is faster than on-premises PAM, and scaling is handled by the vendor, making integrations with cloud services far more straightforward. For teams managing thousands of secrets across multiple cloud environments, SaaS PAM reduces operational burden significantly.The trade-off, however, is third-party dependency and custody. Your credential retrieval depends on the vendor's platform availability, so if that vendor experiences an outage, your access is affected until service resumes.
And if that vendor is breached, your credentials may be exposed, which would increase the concentration risk that DORA Article 28 specifically addresses. For many use cases, this is an acceptable trade-off, but for the highest-sensitivity credentials where a single compromise would be catastrophic, some organizations need an approach that removes that dependency entirely.
Distributed secrets management is an entirely different architecture from the vault model that the above two options rely on.
Instead of storing credentials in a central location, credentials are split into fragments and distributed across multiple devices. Protected credentials are never persisted on any device, and are never exposed at any point.
Many organizations will use distributed secrets management alongside an existing PAM or secrets management platform as an additional layer for their most critical accounts.
The easiest way to meet any current or future regulation that calls for access management control and auditing 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.
Practically, this means that whenever a routine operation happens, it happens in a compliant way without anyone having to double-check.
SplitSecure gives you that compliance posture for managing privileged credentials.
We developed a distributed secrets management approach specifically for regulatory environments, such as financial services, that require access controls that architecturally enforce secure secrets management practises.
See how SplitSecure helps financial institutions meet DORA, NYDFS, PCI DSS, and SOX requirements for privileged access management.
Our Blog
