Contents
Identity and access management
Explicit identity management requirements (Art. 20 RTS RMF)
BaFin notes that BAIT/VAIT already implied identity management, but DORA now makes it an explicit, documented discipline.
What DORA now explicitly requires
Under Art. 20 RTS RMF, financial entities must have documented identity management guidelines and procedures that ensure:
- Unique identity for every person accessing ICT assets
- Every employee, including staff of ICT third-party providers, must have a unique identity for access to the institution’s information and ICT assets.
- No “shared” identities as a standard operating mode.
- Persistence of unique identities across changes
- Identities must remain unique and traceable even:
- after reorganisations, and
- at the end of the contractual relationship (for forensic / audit purposes).
- Identities must remain unique and traceable even:
- Lifecycle management for identities and accounts
- A full lifecycle process is required:
- creation → modification (job change, role change) → suspension → deletion/archiving.
- DORA explicitly encourages automated solutions for identity & account lifecycle where possible.
- A full lifecycle process is required:
Impact vs. BAIT/VAIT
- BAIT/VAIT already required sound IAM, but did not spell out identity lifecycle and uniqueness so clearly.
- Under DORA, the identity lifecycle becomes a formal control object:
- Own policy
- Own procedures
- Evidence that third-party staff identities are handled the same way as internal ones.
“Need-to-use” principle and strengthened access management (Art. 21 RTS RMF)
The access management part in RTS RMF adds one new principle and tightens some frequencies, otherwise it mostly re-labels BAIT/VAIT ideas.
1. The new principle: “need-to-use”
Art. 21 RTS RMF introduces the “need-to-use” principle as a complement to:
- “need-to-know”
- “least privilege”
from BAIT/VAIT Chapter 6.2.
BaFin’s interpretation:
- In reality, need-to-use ≈ need-to-know/least privilege – it emphasises that access must only exist where there is a concrete operational need to actually use the resource.
- Therefore, no big design change, but:
- it creates an explicit regulatory test (“Is this access really needed for use?”) for recertifications and role definitions.
2. Other access management requirements under DORA
BaFin lists the following as part of DORA’s minimum set:
- Separation of functions must be ensured (classic SoD).
- Generic accounts must be largely limited, so that:
- Activities can always be clearly attributed to a single person.
- Controls to prevent unauthorised access must be in place:
- Preventive, detective and corrective measures.
None of this is conceptually new vs. BAIT/VAIT – but now sits in an EU regulation + RTS, i.e. mandatory and directly auditable.
3. New recertification cycles
Here is a very concrete uplift:
- For all access rights related to critical or important functions
→ recertification every 6 months (Art. 21(1)(e)(iv) RTS RMF). - For all other authorisations
→ annual recertification is sufficient.
Important:
- No distinction between:
- end-user access and
- technical access (service accounts, API accounts)
→ both fall under these recertification cycles.
So, if your current practice is “annual for everyone”, you’ll need to shorten to 6-monthly for all users & technical accounts that touch critical/important functions.
4. Privileged & emergency access
DORA tightens governance for admin / break-glass accounts:
- Privileged emergency or administrative access:
- May only be granted on a “need-to-use” and ad-hoc basis.
- No permanent emergency access lying around.
- Privileged & remote access:
- Must use strong authentication “based on leading practices” (effectively MFA as minimum).
- PAM (Privileged Access Management):
- RTS RMF explicitly says that automated PAM solutions should be used where possible for granting, monitoring and revoking privileged access.
Compared to BAIT/VAIT, this raises the bar:
- PAM was good practice;
- Under DORA, PAM-like controls become expected for proportionality-relevant institutions, especially where critical/important functions are involved.
Source: BaFin, Supervisory statement: Guidance notes on the implementation of DORA for ICT risk management and ICT third-party risk management