A notified eID scheme is a government-recognised electronic identity arrangement that can be used to authenticate a person with a defined assurance level across participating jurisdictions. In AMLR onboarding, it is one of several acceptable identity routes, but its coverage is not uniform across Member States.
What a notified eID scheme is for
A notified eID scheme is a government-recognised electronic identity arrangement used to authenticate a person at a defined assurance level across participating jurisdictions. In practice, it helps organisations accept a recognised identity method without building a separate country-by-country identity process.
How notified eID schemes fit cross-border identity assurance
These schemes matter because they standardise trust across borders: the relying party does not need to interpret each national login method from scratch, but can rely on the notified scheme and its assurance statement. That is especially important where a business, public service, or regulated onboarding flow needs a consistent proof of identity rather than a locally created account.
For teams working through European digital identity requirements, NHIMG’s Digital Identity, eID and Identity Wallets Guide is the most direct place to understand how national eID, wallets, and verifiable credentials fit together.
Coverage still varies by jurisdiction, so “notified” does not mean universally available. The practical question is whether the scheme is recognised in the countries and service flows you actually need to support, and whether the assurance level meets the relying party’s acceptance rules.
Why assurance level and interoperability matter
The assurance level is the core security property. It indicates how much confidence the relying party can place in the identity result, which in turn affects whether the scheme is suitable for low, medium, or higher-risk onboarding and authentication use cases.
Interoperability is equally important because cross-border identity is only useful when authentication outcomes are understood consistently by both the sending and receiving side. That means the scheme must be treated as part of an identity trust framework, not just as a login button.
When you evaluate a notified eID route, the main operational question is whether the identity proofing and authentication strength align with the risk of the transaction. A scheme can be valid for one workflow and still be too weak or too limited for another.
For baseline control language around identification and authentication, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful control catalog, while NIST SP 800-63 Digital Identity Guidelines is the better reference for assurance, proofing, and authenticator strength.
How organisations assess and use a notified eID route
Organisations usually assess this option from two angles: whether the scheme is legally and operationally available for the target population, and whether the assurance level is sufficient for the onboarding decision. If either side fails, the scheme may still be valid in theory but unusable in practice.
That makes implementation planning important. Product, compliance, and identity teams need to know which jurisdictions are covered, what evidence is returned, what fallback journeys exist, and how exceptions are handled when a user cannot rely on a notified scheme.
If your programme is built around European digital identity, the scheme should be mapped to the broader trust architecture rather than treated as a standalone login method. That is the point where relying-party acceptance, user journey design, and identity governance meet.
Risk and Threat Considerations
Notified eID schemes reduce fragmentation, but they also create dependency on the availability, coverage, and trustworthiness of a cross-border identity ecosystem. If the scheme is unavailable in a given jurisdiction or at a needed assurance level, organisations may be forced into weaker fallback onboarding paths.
Failure mechanism: Incomplete coverage, misaligned assurance expectations, or acceptance of a scheme outside its intended trust boundary can lead to failed onboarding, inconsistent identity assurance, or reliance on alternate flows that are easier to abuse.
Impact: The result can be customer drop-off, control bypass, or a mismatch between the identity assurance used for access decisions and the actual risk of the transaction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Notified eID schemes authenticate external people across jurisdictions. |
| Recommendation — Map notified eID acceptance to IA-8 so external-user authentication strength matches the onboarding risk. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Defines assurance, proofing, and authenticator concepts central to notified eID trust. |
| Recommendation — Use 800-63 assurance and proofing guidance to set acceptance criteria for notified eID routes. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Notified eID schemes depend on trusted authentication information and controlled identity evidence. |
| Recommendation — Apply A.5.17 to govern how identity evidence and authentication data are accepted and protected. | ||
Practitioner Guidance
Governance implication: Treat notified eID as one approved identity route in a broader onboarding policy, not as a universal replacement for local identity checks. The acceptance decision should be tied to the jurisdiction, the assurance level, and the business risk of the workflow.
What to watch for: Watch for inconsistent country coverage, unclear fallback rules, and service teams assuming that “government-recognised” automatically means “sufficient for every use case.” The identity decision still needs explicit control ownership.
Related resources from NHI Mgmt Group
- What is the difference between an EU digital identity wallet and a national eID scheme?
- How should scheme operators govern OpenID for Verifiable Credentials implementations?
- What should organisations change after a large-scale labour fraud scheme?
- How should teams choose between self-assessment and notified body review for high-risk AI systems?