DORA leaves banks surprisingly little room on privileged access management. Its technical standard spells out how administrator, emergency and other privileged accounts are granted, reviewed and removed. Meeting it takes a PAM specialist who can design that process, alongside the engineer who builds the tooling.
DORA has applied since 17 January 2025, yet plenty of firms were still catching up well after that date. When De Nederlandsche Bank (DNB), the Dutch central bank and prudential supervisor, surveyed the sector in May 2025, many institutions said they expected to need until the end of 2025 or later to finish implementation. My expectation is that access management will be one of the first things auditors pick up, precisely because the rules are so specific.
What DORA requires for privileged access
The detail sits in Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024, the regulatory technical standard on ICT risk management under DORA. Article 21 covers access control, and these are the parts that matter for PAM:
- Access rights follow need-to-know, need-to-use and least privilege.
- Generic and shared accounts are kept to a minimum, as far as possible.
- Privileged, emergency and administrator access is granted on a need-to-use or ad-hoc basis, for all ICT systems rather than just the critical ones.
- Access rights are updated at least once a year, and at least every six months for systems supporting critical or important functions.
- Access is withdrawn without undue delay when someone leaves.
- Privileged access and remote access to the network require strong authentication.
The emergency access point deserves a careful read. As I read it, a break-glass account that is permanently enabled does not fit. Nor does an administrator who holds domain admin rights all year round for convenience.
Where banks tend to get stuck
A six-monthly review sounds manageable until you try to run one. You first need to know which systems support critical or important functions, and which accounts on those systems are privileged. Building that inventory is most of the job. It means tracking down service accounts a project team created years ago, local admin accounts on individual servers, and the admin account of an outside supplier that has used the same login for years.
Those outside parties need particular attention. A managed service provider logging in remotely to your network falls under the same strong authentication requirement, so whoever owns ICT third-party risk has to sit down with the PAM specialist early. For what to test a third-party risk specialist on, see our interview questions for a TPRM specialist under DORA.
Generic accounts are the other sticking point. The standard asks you to limit them, which stops short of a ban. My advice is to make sure that for every shared account you keep, you can show who used it and when. A password vault with session recording is built for exactly that.
The PAM roles a bank needs
PAM at a bank is more than a one-person job. I split it into three roles. A smaller institution can ask one experienced specialist to cover two of them, as long as everyone accepts that some work will move more slowly.
A PAM architect or PAM lead decides which accounts come under PAM and designs the processes for requesting, approving, emergency use and removal. This person turns Article 21 into a policy an auditor can test, which means regular contact with the CISO, internal audit and system owners.
A PAM engineer builds the technical side: the vault, session management, just-in-time access, integration with the directory and the SIEM, and onboarding systems one by one. Ask specifically about experience with the platform you run or plan to buy. Someone who knows a different product will get there, but budget for a learning curve.
An access governance specialist runs the periodic reviews, makes sure managers and system owners actually check the rights they sign off, and links leavers to prompt removal of access. The role overlaps with IAM. Our piece on IAM versus CIAM profiles helps you work out which one you need.
Process first, tooling second
My advice: don't make a PAM engineer your first hire. Start with someone who builds the inventory and designs the process. Roll out a PAM tool before you know which accounts you have, and the vault fills up with whatever happens to turn up. With the groundwork done, the engineer moves much faster, because it is clear what goes in and who is allowed what.
The opposite risk is real too: a polished policy document and no technical change behind it. So bring the engineer in shortly after the architect, as soon as the first batch of accounts is mapped. Start with the systems supporting critical or important functions. They carry the strictest review cycle, and they are where an auditor will look first.
Interim, secondment or permanent?
Implementing PAM is a project with a clear start and finish, which suits an interim or freelance PAM specialist who has done it before at a financial institution and already knows what auditors expect to see. Once the build is done, the reviews, onboarding of new systems and day-to-day vault management carry on. That work belongs with your own staff, a seconded specialist or a permanent hire.
Pair someone from your own team with the interim specialist from week one. Otherwise the knowledge walks out of the door when the assignment ends.
We provide freelance and interim PAM specialists from a network of 7,000+ vetted professionals and present the first candidate within 4 hours. Have a look at our PAM expertise, read what is happening in banking and finance, or call or email me if you want to talk through which role to fill first.
