DORA, NIS2 & PSD3: The 2026 Authentication Requirements Checklist

TL;DR

• Three EU regimes now converge on the same authentication baseline: DORA (ICT risk for finance), NIS2 (strong auth + audit logging for essential and important entities), and PSD3/PSR (strong customer authentication for payments).
• In practice they demand four capabilities: phishing-resistant MFA, tamper-evident audit trails, disciplined cryptographic key management, and demonstrable access governance.
• A tamper-evident audit log built on a BLAKE3 Merkle chain lets you prove to an auditor that logs were not altered after the fact - a recurring ask across all three regimes.
• Use the capability checklist below to map each obligation to a control, then download the full gated PDF version for your audit pack.

What authentication does DORA, NIS2 and PSD3 require in 2026?

DORA, NIS2 and PSD3 do not publish a single shared “authentication standard,” but together they require regulated EU entities to deploy phishing-resistant multi-factor authentication, keep tamper-evident audit trails of access and key events, manage cryptographic keys under documented controls, and prove those controls on demand. The overlap is large enough to satisfy with one well-designed identity layer.

If you run a bank, a payment service, critical infrastructure, or a digital service that EU law now classes as “essential” or “important,” your identity provider has quietly become a compliance artifact. Auditors no longer ask only whether you have MFA - they ask whether it resists phishing, whether your access logs can be trusted, and whether you can show the chain of custody for your signing keys. This checklist maps each regulation to the authentication capability that answers it.

CAI Technology is not a government authority; the guidance below is engineering interpretation of public EU legal texts, not legal advice. Cite the primary sources linked inline and confirm scope with your compliance counsel.

The three regimes at a glance

The practical takeaway is that these three regimes were drafted by different directorates for different purposes - operational resilience, network security, and payment fraud - yet they converge on the same controls when you reduce them to authentication primitives.

How to read this diagram: The left column is the three regulations; the middle column is the specific authentication obligation each one imposes; the right column is the engineering capability that satisfies it. The point of the fan-in is that distinct legal obligations - DORA’s access control, NIS2’s Article 21 MFA mandate, and PSD3’s two-factor SCA rule - all collapse onto the same control, phishing-resistant MFA. Reading the chart this way stops teams from building three parallel compliance programs when one well-architected identity layer covers all three. It also exposes where a single weakness, such as a non-tamper-evident log, would create findings under both DORA and NIS2 simultaneously.

DORA: ICT risk and the authentication angle

DORA (Regulation (EU) 2022/2554), applicable since January 2025, is an operational-resilience regulation for the EU financial sector. Its ICT risk-management framework (Articles 5-15) requires financial entities to implement “strong authentication mechanisms” and access controls based on least privilege, and to maintain logs that record ICT-related events in a way that supports incident reconstruction and supervisory review.

For authentication that translates to three concrete asks. First, privileged and remote access must use multi-factor authentication that is resistant to interception and replay. Second, every authentication and key-management event must be logged with integrity guarantees - an auditor reconstructing an incident must be able to trust that the log was not edited after the breach. Third, the cryptographic keys underpinning your identity provider (token-signing keys, in particular) fall squarely inside DORA’s ICT asset inventory and change-management expectations. A signing key is a root of trust; DORA wants you to manage it like one.

NIS2: strong authentication plus secured logging

NIS2 (Directive (EU) 2022/2555) widens the old NIS scope to eighteen sectors and tightens the baseline. Article 21 enumerates the minimum risk-management measures, and it explicitly names “the use of multi-factor authentication or continuous authentication solutions” and “secured voice, video and text communications,” alongside policies on cryptography and access control.

Two authentication-relevant duties dominate. The first is strong authentication across the estate - not just for customers but for administrators, service accounts, and remote staff, which is precisely where credential-phishing attacks land. NIS2 raises the cost of weak MFA because management bodies can be held personally accountable for non-compliance. The second duty is logging you can defend: incident-handling and reporting obligations are meaningless if the underlying logs can be silently rewritten. Member State transpositions throughout 2024-2025 have generally read “secured logging” to mean integrity-protected, retained, and reviewable - exactly what a tamper-evident audit trail delivers.

For the sovereignty dimension of why where your identity provider runs also matters under these regimes, see our analysis of EU sovereign identity versus the US CLOUD Act.

PSD3 / SCA: what changes versus PSD2

The payments package - the PSD3 directive and the Payment Services Regulation (PSR) - reaffirms and modernizes Strong Customer Authentication. SCA still rests on two independent factors drawn from knowledge, possession, and inherence, with dynamic linking that binds each authentication to a specific amount and payee. The EBA Regulatory Technical Standards on SCA remain the detailed rulebook.

What is new is the direction of travel. PSD3/PSR sharpens the obligation to make SCA accessible (so providers cannot lean on a single channel like SMS), strengthens transaction-monitoring and anti-fraud expectations, addresses authentication for vulnerable users, and tightens liability for fraud enabled by spoofing. The clear signal is away from SMS one-time codes - which are phishable and interceptable - and toward possession factors bound to hardware. That makes hardware-backed, phishing-resistant MFA the safe design target for any payment flow you build today.

The capability checklist: mapping obligations to controls

Here is the consolidated mapping. Each row pairs a regulatory obligation with the authentication capability that satisfies it and a one-line implementation note.

The single line item that surprises most teams is the audit trail. Everyone has logs; few can prove their logs were not altered after an incident. That is the gap a tamper-evident design closes.

Why a tamper-evident audit trail matters - and how to verify one

DORA and NIS2 both want logs you can defend, not just logs you keep. The distinction is integrity: if an attacker (or an insider) can edit the audit record after the fact, the record is worthless as evidence. The fix is to make any modification mathematically detectable.

CAI-AUTH’s audit log is a public example of this pattern: it is a tamper-evident audit chain built on a BLAKE3 Merkle structure. Each event is hashed, each hash is folded into a running chain, and the chain produces a compact root that summarizes the entire history. To verify, an auditor recomputes the hashes; if a single past entry was altered, every downstream hash and the final root no longer match, and the tampering is exposed. The benefit for a regulated buyer is direct: you can hand an auditor a verifiable proof that your access and key-management logs are intact, satisfying the integrity expectation in both DORA logging and NIS2 secured-logging clauses - without trusting the operator’s word. (CAI Technology is not a government authority; this is a product capability, not a regulatory certification.)

How to read this diagram: Each log entry on the left is hashed, and the hashes are combined pairwise up the chain until they produce a single Merkle root on the right. The verifier recomputes that root from the stored entries and compares it to the published root. If every entry is original, the recomputed root matches and the log is certified intact; if any entry - say, “Entry 3” - was changed after the fact, its hash changes, that change ripples through every parent link, and the final root no longer matches, so the branch flips to “tampering detected.” This is why a Merkle-chained log is tamper-evident rather than merely tamper-resistant: you cannot quietly rewrite history, because the math makes the alteration visible to anyone who checks.

For how the possession factor in this picture is anchored to real hardware (and why an identity provider should reject rooted or emulated devices), this connects to the broader move toward eIDAS 2.0 and the EU Digital Identity Wallet, where wallet-grade assurance and these compliance regimes increasingly meet.

Where CAI-AUTH fits

CAI-AUTH is an EU-operated, self-hostable OIDC identity provider written in Rust. It ships phishing-resistant tap-to-approve push authentication with mandatory hardware attestation, the BLAKE3 Merkle tamper-evident audit log described above, Shamir 3-of-5 account recovery, and post-quantum composite signing (CAI-PQ-HYBRID-87-Ed25519). Its compliance posture is documented for DORA, NIS2, PSD3, eIDAS 2.0, PCI-DSS and GDPR. See the full mapping on the CAI-AUTH compliance page. CAI Technology is not a government authority.

FAQ

Does DORA require MFA?

DORA does not name “MFA” as a single bullet, but its ICT risk-management framework (Articles 5-15 of Regulation (EU) 2022/2554) requires strong authentication and least-privilege access control for ICT systems. In practice supervisors read this as multi-factor authentication for privileged and remote access, backed by integrity-protected logging of authentication events.

What authentication does NIS2 require?

NIS2 (Directive (EU) 2022/2555), Article 21, lists minimum risk-management measures that explicitly include “the use of multi-factor authentication or continuous authentication solutions,” along with cryptography and access-control policies and secured logging. It applies to essential and important entities, and management bodies can be held accountable for failing to implement these measures.

What changes for SCA under PSD3?

PSD3 and the PSR reaffirm Strong Customer Authentication - two independent factors plus dynamic linking - while pushing providers away from phishable SMS codes toward hardware-bound possession factors, strengthening anti-fraud and transaction monitoring, improving accessibility of SCA, and tightening liability for spoofing-enabled fraud. The EBA SCA RTS remain the detailed technical rulebook.

How do I prove my audit logs were not tampered with?

Use a tamper-evident log: hash each entry and chain the hashes into a Merkle structure that yields a single verifiable root. An auditor recomputes the root from stored entries; any post-hoc edit changes a hash, breaks the chain, and makes the root mismatch. CAI-AUTH implements this with a BLAKE3 Merkle audit chain.

Can one identity layer satisfy DORA, NIS2 and PSD3 at once?

Largely, yes. Although the three regimes have different scopes, their authentication obligations converge on phishing-resistant MFA, tamper-evident audit trails, and disciplined key management. A single identity provider that delivers all three - and documents the mapping - lets you cover the shared baseline once rather than building parallel compliance programs.

Download the full checklist (PDF). Get the complete, audit-ready DORA / NIS2 / PSD3 authentication checklist - every obligation mapped to a control, with implementation notes and evidence prompts - as a gated PDF. Request the checklist.

Last updated: 2026-06-27. CAI TECHNOLOGY SRL, CUI 50512457. CAI Technology is not a government authority. This article is engineering guidance, not legal advice.