Platform
Solutions
Resources
Company
Platform
Solutions
Resources
Company
Challenges
DORA and NIS2 authentication requirements
DORA Article 9(4)(d) requires financial entities to implement strong authentication mechanisms and protection measures of cryptographic keys. NIS2 Article 21(2)(j) mandates multi-factor authentication or continuous authentication solutions and is the first EU directive to name MFA in the text of the law itself. Both frameworks target credential-based attacks as the primary risk category. WWPass zero-trust distributed architecture maps to the authentication and access control requirements of both frameworks.
Challenges
DORA and NIS2 authentication requirements
DORA Article 9(4)(d) requires financial entities to implement strong authentication mechanisms and protection measures of cryptographic keys. NIS2 Article 21(2)(j) mandates multi-factor authentication or continuous authentication solutions and is the first EU directive to name MFA in the text of the law itself. Both frameworks target credential-based attacks as the primary risk category. WWPass zero-trust distributed architecture maps to the authentication and access control requirements of both frameworks.
Challenges
DORA and NIS2 authentication requirements
DORA Article 9(4)(d) requires financial entities to implement strong authentication mechanisms and protection measures of cryptographic keys. NIS2 Article 21(2)(j) mandates multi-factor authentication or continuous authentication solutions and is the first EU directive to name MFA in the text of the law itself. Both frameworks target credential-based attacks as the primary risk category. WWPass zero-trust distributed architecture maps to the authentication and access control requirements of both frameworks.
DORA: what Article 9 requires
The Digital Operational Resilience Act entered into application on January 17, 2025. It applies directly and uniformly across all EU member states to financial entities including banks, insurers, investment firms, fintech companies, and payment institutions.
Article 9 (Protection and Prevention) is the primary article governing authentication. Two provisions are directly relevant:
Article 9(4)(c) requires financial entities to implement policies that limit physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions only. This is the least-privilege principle stated as a legal obligation.
Article 9(4)(d) requires financial entities to implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems, and protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes.
Article 23 extends the obligation to ICT third-party risk management, requiring financial entities to manage access rights and prevent unauthorized access by third-party providers. This directly implicates vendor cloud dependencies in authentication recovery flows.
Explore "Digital Operational Resilience Act"↗
Explore WWPass for financial services & fintech
NIS2: what Article 21 requires
The NIS2 Directive (EU 2022/2555) applies to essential and important entities across 18 sectors including energy, banking, healthcare, digital infrastructure, transport, water, and public administration. Member states were required to transpose it into national law by October 17, 2024.
Article 21 is the operational core of the directive, requiring appropriate and proportionate technical, operational and organisational measures to manage cybersecurity risks. Article 21(2)(j) explicitly lists multi-factor authentication or continuous authentication solutions. NIS2 is the first major EU directive to mandate MFA in the text of the law itself rather than in delegated guidance.
Implementing Regulation 2024/2690 provides technical detail on which authentication factors qualify. The supervisory consensus across ENISA, ANSSI, and BSI now aligns on phishing-resistant authentication as the expected standard rather than any MFA method being sufficient.
Explore WWPass for government & public sector
Where credential-based authentication creates gaps under both frameworks
Both DORA and NIS2 were designed in direct response to credential-based attacks. Stolen credentials remain the dominant initial access vector across the sectors both frameworks cover. The regulations are the legal expression of a documented, ongoing threat.
Three specific gaps in current authentication approaches are relevant under both frameworks:
Username exposure: service providers store usernames or email addresses to identify users. These are breach targets. DORA Article 9(4)(c) and NIS2 Article 21(2)(i) both require access to be limited to what is necessary for approved functions. A stored username that persists beyond the authentication event is an unnecessary retained identity.
Vendor cloud dependency: passkey recovery depends on iCloud Keychain, Google Password Manager, or Microsoft account sync. DORA Article 23 requires financial entities to manage ICT third-party risk and maintain control over access rights. Delegating authentication recovery to a third-party cloud provider creates direct third-party ICT risk exposure.
Credential reuse risk: shared passwords, reused credentials, and phishable authentication methods are exactly what both Article 9(4)(d) and NIS2 Article 21(2)(j) were written to eliminate.
How WWPass architecture maps to the requirements
The following table maps specific DORA and NIS2 requirements to architectural properties of WWPass. All mappings describe architectural alignment. They do not constitute certification or guarantee of regulatory compliance.
Framework | Article | Requirement | How WWPass maps |
DORA | Art. 9(4)(c) | Limit access to what is required for approved functions only | PUID generates a distinct opaque identifier per user per service. No persistent identity is stored. Access is bounded to the specific user-service relationship. |
DORA | Art. 9(4)(d) | Strong authentication mechanisms and cryptographic key protection | Authentication uses cryptographic keys, not passwords. Data is encrypted with keys derived from the UserID and SPID combination. No master key exists. |
DORA | Art. 23 | ICT third-party risk management, control over access rights | Recovery uses WWPass's own distributed architecture. No third-party cloud dependency. Data stays within the financial entity's control perimeter. |
NIS2 | Art. 21(2)(j) | Multi-factor authentication or continuous authentication | WWPass Key satisfies the possession factor. Optional PIN or biometric satisfies a second factor. Continuous authentication monitoring with automatic access revocation is supported. |
NIS2 | Art. 21(2)(i) | Access control policies and identity and access management | No username stored on the service side. Each service receives only a PUID. Self-service key management with full revocation capability. |
Both | Phishing resistance | Implementing Regulation 2024/2690 aligns on phishing-resistant as expected standard | QR codes contain only one-time session tickets. Nothing reusable is transmitted. Nothing can be phished. |
Who is in scope
DORA covers financial entities including banks, credit institutions, insurance and reinsurance undertakings, investment firms, crypto-asset service providers, payment institutions, and electronic money institutions operating in the EU. Even non-EU providers supplying services to EU financial entities must meet DORA-aligned standards contractually.
NIS2 covers essential entities in Annex I sectors (energy, banking, healthcare, digital infrastructure, transport, water, public administration) and important entities in Annex II sectors. Roughly 160,000 organisations across the EU are in scope. Organizations in the supply chain of an in-scope entity increasingly face contractual requirements to meet NIS2-aligned standards even where they are not directly covered.
Explore WWPass for government & public sector, healthcare, and financial services & fintech
Frequently asked questions
Q: Does WWPass comply with DORA?
A: WWPass architecture maps to the authentication and access control requirements of DORA Article 9. Specifically, the zero-trust distributed architecture with cryptographic key-based authentication addresses Article 9(4)(d)'s requirement for strong authentication mechanisms and cryptographic key protection. The absence of a vendor cloud dependency in recovery addresses Article 23's ICT third-party risk obligations. Whether a specific deployment satisfies DORA compliance requirements depends on the financial entity's full ICT risk management framework and the scope of their DORA obligations. Independent legal and compliance review is required before making regulatory compliance claims.
Q: Does WWPass satisfy NIS2 Article 21(2)(j) MFA requirements?
A: WWPass WWPass Key satisfies the possession factor under NIS2 Article 21(2)(j). An optional PIN satisfies the knowledge factor and biometric the inherence factor. Continuous authentication monitoring with automatic access rights revocation is also supported. The Implementing Regulation 2024/2690 aligns on phishing-resistant authentication as the expected standard. WWPass uses one-time session tickets that cannot be reused or phished. Whether a specific deployment satisfies NIS2 Article 21 requirements for a given entity depends on their full risk assessment and the national transposition in their jurisdiction.
Q: What is the difference between DORA and NIS2 for authentication?
A: DORA is an EU regulation that applies directly and uniformly to financial entities without national transposition. It entered into application January 17, 2025. NIS2 is a directive that required member state transposition by October 17, 2024, so specific requirements vary by country. Both mandate strong authentication and access controls. DORA's Article 9 focuses on cryptographic key protection and least-privilege access within ICT risk management. NIS2's Article 21(2)(j) mandates MFA or continuous authentication as one of ten specific cybersecurity risk management measures.
Q: Does vendor cloud dependency for passkey recovery create a DORA risk?
A: Yes, it is a relevant consideration under DORA Article 23. When passkey recovery depends on iCloud Keychain, Google Password Manager, or Microsoft account sync, a third-party cloud provider holds a copy of authentication credentials. Article 23 requires financial entities to manage ICT third-party risk and maintain control over access rights. The extent to which this creates a DORA compliance gap depends on the entity's specific risk assessment and contractual arrangements with those providers.
Q: Which sectors must comply with NIS2 Article 21 authentication requirements?
A: NIS2 essential entities in Annex I sectors must comply: energy, banking, financial market infrastructure, healthcare, digital infrastructure, ICT service management, public administration, and space. Important entities in Annex II sectors (postal services, waste management, food production, manufacturing, digital providers) face the same technical requirements under Article 21 but are subject to reactive rather than proactive supervision. Organizations in the supply chain of in-scope entities increasingly face contractual requirements to meet NIS2-aligned standards.
DORA: what Article 9 requires
The Digital Operational Resilience Act entered into application on January 17, 2025. It applies directly and uniformly across all EU member states to financial entities including banks, insurers, investment firms, fintech companies, and payment institutions.
Article 9 (Protection and Prevention) is the primary article governing authentication. Two provisions are directly relevant:
Article 9(4)(c) requires financial entities to implement policies that limit physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions only. This is the least-privilege principle stated as a legal obligation.
Article 9(4)(d) requires financial entities to implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems, and protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes.
Article 23 extends the obligation to ICT third-party risk management, requiring financial entities to manage access rights and prevent unauthorized access by third-party providers. This directly implicates vendor cloud dependencies in authentication recovery flows.
Explore "Digital Operational Resilience Act"↗
Explore WWPass for financial services & fintech
NIS2: what Article 21 requires
The NIS2 Directive (EU 2022/2555) applies to essential and important entities across 18 sectors including energy, banking, healthcare, digital infrastructure, transport, water, and public administration. Member states were required to transpose it into national law by October 17, 2024.
Article 21 is the operational core of the directive, requiring appropriate and proportionate technical, operational and organisational measures to manage cybersecurity risks. Article 21(2)(j) explicitly lists multi-factor authentication or continuous authentication solutions. NIS2 is the first major EU directive to mandate MFA in the text of the law itself rather than in delegated guidance.
Implementing Regulation 2024/2690 provides technical detail on which authentication factors qualify. The supervisory consensus across ENISA, ANSSI, and BSI now aligns on phishing-resistant authentication as the expected standard rather than any MFA method being sufficient.
Explore WWPass for government & public sector
Where credential-based authentication creates gaps under both frameworks
Both DORA and NIS2 were designed in direct response to credential-based attacks. Stolen credentials remain the dominant initial access vector across the sectors both frameworks cover. The regulations are the legal expression of a documented, ongoing threat.
Three specific gaps in current authentication approaches are relevant under both frameworks:
Username exposure: service providers store usernames or email addresses to identify users. These are breach targets. DORA Article 9(4)(c) and NIS2 Article 21(2)(i) both require access to be limited to what is necessary for approved functions. A stored username that persists beyond the authentication event is an unnecessary retained identity.
Vendor cloud dependency: passkey recovery depends on iCloud Keychain, Google Password Manager, or Microsoft account sync. DORA Article 23 requires financial entities to manage ICT third-party risk and maintain control over access rights. Delegating authentication recovery to a third-party cloud provider creates direct third-party ICT risk exposure.
Credential reuse risk: shared passwords, reused credentials, and phishable authentication methods are exactly what both Article 9(4)(d) and NIS2 Article 21(2)(j) were written to eliminate.
How WWPass architecture maps to the requirements
The following table maps specific DORA and NIS2 requirements to architectural properties of WWPass. All mappings describe architectural alignment. They do not constitute certification or guarantee of regulatory compliance.
Framework | Article | Requirement | How WWPass maps |
DORA | Art. 9(4)(c) | Limit access to what is required for approved functions only | PUID generates a distinct opaque identifier per user per service. No persistent identity is stored. Access is bounded to the specific user-service relationship. |
DORA | Art. 9(4)(d) | Strong authentication mechanisms and cryptographic key protection | Authentication uses cryptographic keys, not passwords. Data is encrypted with keys derived from the UserID and SPID combination. No master key exists. |
DORA | Art. 23 | ICT third-party risk management, control over access rights | Recovery uses WWPass's own distributed architecture. No third-party cloud dependency. Data stays within the financial entity's control perimeter. |
NIS2 | Art. 21(2)(j) | Multi-factor authentication or continuous authentication | WWPass Key satisfies the possession factor. Optional PIN or biometric satisfies a second factor. Continuous authentication monitoring with automatic access revocation is supported. |
NIS2 | Art. 21(2)(i) | Access control policies and identity and access management | No username stored on the service side. Each service receives only a PUID. Self-service key management with full revocation capability. |
Both | Phishing resistance | Implementing Regulation 2024/2690 aligns on phishing-resistant as expected standard | QR codes contain only one-time session tickets. Nothing reusable is transmitted. Nothing can be phished. |
Who is in scope
DORA covers financial entities including banks, credit institutions, insurance and reinsurance undertakings, investment firms, crypto-asset service providers, payment institutions, and electronic money institutions operating in the EU. Even non-EU providers supplying services to EU financial entities must meet DORA-aligned standards contractually.
NIS2 covers essential entities in Annex I sectors (energy, banking, healthcare, digital infrastructure, transport, water, public administration) and important entities in Annex II sectors. Roughly 160,000 organisations across the EU are in scope. Organizations in the supply chain of an in-scope entity increasingly face contractual requirements to meet NIS2-aligned standards even where they are not directly covered.
Explore WWPass for government & public sector, healthcare, and financial services & fintech
Frequently asked questions
Q: Does WWPass comply with DORA?
A: WWPass architecture maps to the authentication and access control requirements of DORA Article 9. Specifically, the zero-trust distributed architecture with cryptographic key-based authentication addresses Article 9(4)(d)'s requirement for strong authentication mechanisms and cryptographic key protection. The absence of a vendor cloud dependency in recovery addresses Article 23's ICT third-party risk obligations. Whether a specific deployment satisfies DORA compliance requirements depends on the financial entity's full ICT risk management framework and the scope of their DORA obligations. Independent legal and compliance review is required before making regulatory compliance claims.
Q: Does WWPass satisfy NIS2 Article 21(2)(j) MFA requirements?
A: WWPass WWPass Key satisfies the possession factor under NIS2 Article 21(2)(j). An optional PIN satisfies the knowledge factor and biometric the inherence factor. Continuous authentication monitoring with automatic access rights revocation is also supported. The Implementing Regulation 2024/2690 aligns on phishing-resistant authentication as the expected standard. WWPass uses one-time session tickets that cannot be reused or phished. Whether a specific deployment satisfies NIS2 Article 21 requirements for a given entity depends on their full risk assessment and the national transposition in their jurisdiction.
Q: What is the difference between DORA and NIS2 for authentication?
A: DORA is an EU regulation that applies directly and uniformly to financial entities without national transposition. It entered into application January 17, 2025. NIS2 is a directive that required member state transposition by October 17, 2024, so specific requirements vary by country. Both mandate strong authentication and access controls. DORA's Article 9 focuses on cryptographic key protection and least-privilege access within ICT risk management. NIS2's Article 21(2)(j) mandates MFA or continuous authentication as one of ten specific cybersecurity risk management measures.
Q: Does vendor cloud dependency for passkey recovery create a DORA risk?
A: Yes, it is a relevant consideration under DORA Article 23. When passkey recovery depends on iCloud Keychain, Google Password Manager, or Microsoft account sync, a third-party cloud provider holds a copy of authentication credentials. Article 23 requires financial entities to manage ICT third-party risk and maintain control over access rights. The extent to which this creates a DORA compliance gap depends on the entity's specific risk assessment and contractual arrangements with those providers.
Q: Which sectors must comply with NIS2 Article 21 authentication requirements?
A: NIS2 essential entities in Annex I sectors must comply: energy, banking, financial market infrastructure, healthcare, digital infrastructure, ICT service management, public administration, and space. Important entities in Annex II sectors (postal services, waste management, food production, manufacturing, digital providers) face the same technical requirements under Article 21 but are subject to reactive rather than proactive supervision. Organizations in the supply chain of in-scope entities increasingly face contractual requirements to meet NIS2-aligned standards.
DORA: what Article 9 requires
The Digital Operational Resilience Act entered into application on January 17, 2025. It applies directly and uniformly across all EU member states to financial entities including banks, insurers, investment firms, fintech companies, and payment institutions.
Article 9 (Protection and Prevention) is the primary article governing authentication. Two provisions are directly relevant:
Article 9(4)(c) requires financial entities to implement policies that limit physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions only. This is the least-privilege principle stated as a legal obligation.
Article 9(4)(d) requires financial entities to implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems, and protection measures of cryptographic keys whereby data is encrypted based on results of approved data classification and ICT risk assessment processes.
Article 23 extends the obligation to ICT third-party risk management, requiring financial entities to manage access rights and prevent unauthorized access by third-party providers. This directly implicates vendor cloud dependencies in authentication recovery flows.
Explore "Digital Operational Resilience Act"↗
Explore WWPass for financial services & fintech
NIS2: what Article 21 requires
The NIS2 Directive (EU 2022/2555) applies to essential and important entities across 18 sectors including energy, banking, healthcare, digital infrastructure, transport, water, and public administration. Member states were required to transpose it into national law by October 17, 2024.
Article 21 is the operational core of the directive, requiring appropriate and proportionate technical, operational and organisational measures to manage cybersecurity risks. Article 21(2)(j) explicitly lists multi-factor authentication or continuous authentication solutions. NIS2 is the first major EU directive to mandate MFA in the text of the law itself rather than in delegated guidance.
Implementing Regulation 2024/2690 provides technical detail on which authentication factors qualify. The supervisory consensus across ENISA, ANSSI, and BSI now aligns on phishing-resistant authentication as the expected standard rather than any MFA method being sufficient.
Explore WWPass for government & public sector
Where credential-based authentication creates gaps under both frameworks
Both DORA and NIS2 were designed in direct response to credential-based attacks. Stolen credentials remain the dominant initial access vector across the sectors both frameworks cover. The regulations are the legal expression of a documented, ongoing threat.
Three specific gaps in current authentication approaches are relevant under both frameworks:
Username exposure: service providers store usernames or email addresses to identify users. These are breach targets. DORA Article 9(4)(c) and NIS2 Article 21(2)(i) both require access to be limited to what is necessary for approved functions. A stored username that persists beyond the authentication event is an unnecessary retained identity.
Vendor cloud dependency: passkey recovery depends on iCloud Keychain, Google Password Manager, or Microsoft account sync. DORA Article 23 requires financial entities to manage ICT third-party risk and maintain control over access rights. Delegating authentication recovery to a third-party cloud provider creates direct third-party ICT risk exposure.
Credential reuse risk: shared passwords, reused credentials, and phishable authentication methods are exactly what both Article 9(4)(d) and NIS2 Article 21(2)(j) were written to eliminate.
How WWPass architecture maps to the requirements
The following table maps specific DORA and NIS2 requirements to architectural properties of WWPass. All mappings describe architectural alignment. They do not constitute certification or guarantee of regulatory compliance.
Framework | Article | Requirement | How WWPass maps |
DORA | Art. 9(4)(c) | Limit access to what is required for approved functions only | PUID generates a distinct opaque identifier per user per service. No persistent identity is stored. Access is bounded to the specific user-service relationship. |
DORA | Art. 9(4)(d) | Strong authentication mechanisms and cryptographic key protection | Authentication uses cryptographic keys, not passwords. Data is encrypted with keys derived from the UserID and SPID combination. No master key exists. |
DORA | Art. 23 | ICT third-party risk management, control over access rights | Recovery uses WWPass's own distributed architecture. No third-party cloud dependency. Data stays within the financial entity's control perimeter. |
NIS2 | Art. 21(2)(j) | Multi-factor authentication or continuous authentication | WWPass Key satisfies the possession factor. Optional PIN or biometric satisfies a second factor. Continuous authentication monitoring with automatic access revocation is supported. |
NIS2 | Art. 21(2)(i) | Access control policies and identity and access management | No username stored on the service side. Each service receives only a PUID. Self-service key management with full revocation capability. |
Both | Phishing resistance | Implementing Regulation 2024/2690 aligns on phishing-resistant as expected standard | QR codes contain only one-time session tickets. Nothing reusable is transmitted. Nothing can be phished. |
Who is in scope
DORA covers financial entities including banks, credit institutions, insurance and reinsurance undertakings, investment firms, crypto-asset service providers, payment institutions, and electronic money institutions operating in the EU. Even non-EU providers supplying services to EU financial entities must meet DORA-aligned standards contractually.
NIS2 covers essential entities in Annex I sectors (energy, banking, healthcare, digital infrastructure, transport, water, public administration) and important entities in Annex II sectors. Roughly 160,000 organisations across the EU are in scope. Organizations in the supply chain of an in-scope entity increasingly face contractual requirements to meet NIS2-aligned standards even where they are not directly covered.
Explore WWPass for government & public sector, healthcare, and financial services & fintech
Frequently asked questions
Q: Does WWPass comply with DORA?
A: WWPass architecture maps to the authentication and access control requirements of DORA Article 9. Specifically, the zero-trust distributed architecture with cryptographic key-based authentication addresses Article 9(4)(d)'s requirement for strong authentication mechanisms and cryptographic key protection. The absence of a vendor cloud dependency in recovery addresses Article 23's ICT third-party risk obligations. Whether a specific deployment satisfies DORA compliance requirements depends on the financial entity's full ICT risk management framework and the scope of their DORA obligations. Independent legal and compliance review is required before making regulatory compliance claims.
Q: Does WWPass satisfy NIS2 Article 21(2)(j) MFA requirements?
A: WWPass WWPass Key satisfies the possession factor under NIS2 Article 21(2)(j). An optional PIN satisfies the knowledge factor and biometric the inherence factor. Continuous authentication monitoring with automatic access rights revocation is also supported. The Implementing Regulation 2024/2690 aligns on phishing-resistant authentication as the expected standard. WWPass uses one-time session tickets that cannot be reused or phished. Whether a specific deployment satisfies NIS2 Article 21 requirements for a given entity depends on their full risk assessment and the national transposition in their jurisdiction.
Q: What is the difference between DORA and NIS2 for authentication?
A: DORA is an EU regulation that applies directly and uniformly to financial entities without national transposition. It entered into application January 17, 2025. NIS2 is a directive that required member state transposition by October 17, 2024, so specific requirements vary by country. Both mandate strong authentication and access controls. DORA's Article 9 focuses on cryptographic key protection and least-privilege access within ICT risk management. NIS2's Article 21(2)(j) mandates MFA or continuous authentication as one of ten specific cybersecurity risk management measures.
Q: Does vendor cloud dependency for passkey recovery create a DORA risk?
A: Yes, it is a relevant consideration under DORA Article 23. When passkey recovery depends on iCloud Keychain, Google Password Manager, or Microsoft account sync, a third-party cloud provider holds a copy of authentication credentials. Article 23 requires financial entities to manage ICT third-party risk and maintain control over access rights. The extent to which this creates a DORA compliance gap depends on the entity's specific risk assessment and contractual arrangements with those providers.
Q: Which sectors must comply with NIS2 Article 21 authentication requirements?
A: NIS2 essential entities in Annex I sectors must comply: energy, banking, financial market infrastructure, healthcare, digital infrastructure, ICT service management, public administration, and space. Important entities in Annex II sectors (postal services, waste management, food production, manufacturing, digital providers) face the same technical requirements under Article 21 but are subject to reactive rather than proactive supervision. Organizations in the supply chain of in-scope entities increasingly face contractual requirements to meet NIS2-aligned standards.
Get WWPass
Download the WWPass Key app and test authentication without a username or password.
Get WWPass
Download the WWPass Key app and test authentication without a username or password.
