Identity Assurance Standards Compared: How NIST, eIDAS, ISO and UK Levels Align

"We need AAL2" and "we need eIDAS substantial" sound like the same requirement, but they come from different standards with different structures, different tests and no official equivalence between them. NIST SP 800-63-4 splits assurance into three separate scales (IAL, AAL and FAL), eIDAS defines one level of assurance for an electronic identification means covering enrolment, management and authentication together, ISO/IEC 29115 offers four generic levels designed for mapping other schemes, the UK digital verification services trust framework builds on GPG 45 confidence profiles, and Canada's Pan-Canadian Trust Framework (PCTF) works through modular conformance criteria. This guide compares them side by side: what each level actually tests, how the scales line up and where they do not, and how to design one identity service that can satisfy several regimes. It is for identity architects, product owners at identity and wallet providers, and relying parties that accept identities from more than one country. Status was checked on official sources on 14 November 2026.

Key takeaways

• The scales measure different things. NIST rates proofing, authentication and federation separately; an eIDAS level of assurance rates the whole electronic identification means, so one eIDAS level corresponds to a combination of NIST levels, not one of them.
• No official crosswalk exists between NIST and eIDAS. Any mapping, including the indicative one in this guide, is an analysis; contracts and regulators should name the standard and level they actually require.
• Authentication tests differ in kind. NIST AAL3 requires a phishing-resistant public-key authenticator with a non-exportable key; eIDAS expresses authentication strength as resistance to attackers of enhanced-basic, moderate or high attack potential.
• ISO/IEC 29115 is the bridge, not the target. It defines four levels of assurance and guidance for mapping other schemes to them, which makes it useful for crosswalks but rarely the requirement a regulator names.
• Machine and agent access needs its own reading. These standards were written for people; workload and agent credentials borrow the authentication and federation parts, never the proofing parts.

The five frameworks at a glance

NIST SP 800-63-4: three separate scales

Rev 4 keeps the three-scale model and puts a five-step Digital Identity Risk Management (DIRM) process in front of it: define the online service, assess impact per user group (Low, Moderate, High), select initial assurance levels, tailor and document, and continuously evaluate. Low impact maps to IAL1/AAL1/FAL1, Moderate to IAL2/AAL2/FAL2 and High to IAL3/AAL3/FAL3, but NIST states the selected levels "may still be different", for example IAL1 and FAL1 with AAL2, and that a service may need no IAL at all.

The volume-level detail lives in the NIST SP 800-63A-4 Identity Proofing (IAL) Guide, the NIST SP 800-63B-4 Authenticator Assurance Levels Guide and the NIST SP 800-63C-4 Federation Assurance Levels Guide.

eIDAS: one level for the whole means

Implementing Regulation (EU) 2015/1502 sets the minimum technical specifications for each level in four groups of requirements: 2.1 enrolment (application and registration, identity proofing and verification for natural and legal persons, binding between them), 2.2 electronic identification means management (design, issuance and activation, suspension and revocation, renewal), 2.3 authentication, and 2.4 management and organisation (information security management, record keeping, staff, technical controls, compliance and audit). A means is only at a level if all four groups meet it.

• Low: the authentication mechanism must make guessing, eavesdropping, replay or manipulation highly unlikely to succeed for an attacker with enhanced-basic attack potential.
• Substantial: adds dynamic authentication and resistance to an attacker with moderate attack potential.
• High: resistance to an attacker with high attack potential, on top of all substantial requirements.

eIDAS 2 (Regulation (EU) 2024/1183) raises the stakes: Article 5a(11) states that European Digital Identity Wallets "shall be provided under an electronic identification scheme with assurance level high", and Member States must provide at least one wallet within 24 months of the entry into force of the relevant implementing acts. See the eIDAS 2.0 and the European Digital Identity Framework Guide.

ISO/IEC 29115, UK DVS and Canada PCTF

• ISO/IEC 29115:2013: the Entity authentication assurance framework specifies four levels of assurance, criteria for each, guidance on mapping other schemes to them, guidance on exchanging authentication results and controls against authentication threats. ISO lists it as confirmed in 2020 and due for revision. See the ISO/IEC 29115 guide.
• UK DVS trust framework 1.0: published under section 28 of the Data (Use and Access) Act 2025, in force from the date the first conformity assessment body is accredited against it, no earlier than 1 September 2026. Identity checks are expressed through GPG 45, which scores evidence, validity, activity history, identity fraud risk and verification into confidence profiles. See the UK Digital Verification Services Trust Framework Guide.
• Canada PCTF: a modular framework from DIACC covering Verified Person (identity proofing), Authentication, Credentials, Digital Wallet, Trust Registries, Privacy, Infrastructure and more. Conformance requirements vary by level of confidence, with a certification programme and a trusted list of certified providers.

How the levels line up

The table below is NHI Mgmt Group's indicative alignment for design planning. None of the publishers has issued it, the frameworks test different things, and an identity can meet one row in one framework while missing it in another. Use it to find gaps, not to claim equivalence.

Where the alignment breaks

• AAL2 vs substantial: AAL2 permits any two distinct factors with approved cryptography; substantial also needs the enrolment, means management and organisational requirements at substantial, so an AAL2 login on top of an IAL1 account does not reach substantial.
• AAL3 vs high: AAL3 is defined by authenticator type (phishing-resistant, non-exportable key); high is defined by attack potential and usually evaluated through certification of the means, so the evidence required is different even when the authenticator is the same.
• IAL3 vs high proofing: IAL3 requires an attended session and biometric collection; eIDAS high proofing is specified in 2015/1502 section 2.1.2 without NIST's wording, so meeting one does not by itself establish the other.
• Federation: only NIST has a federation scale. Under eIDAS the level travels with the identification means; relying parties must still protect the assertion, which FAL2 and FAL3 make explicit.

Threat model and failure modes per framework

Modern proofing attacks such as camera injection and synthetic media put pressure on every framework's remote route. See the Deepfake-Resistant Identity Verification Guide.

Decision guidance: which standard to anchor on

• US federal customers or US-led programmes: anchor on NIST SP 800-63-4 and run DIRM. If you are still on 800-63-3, see NIST SP 800-63-3 to 800-63-4 Migration.
• EU public services, regulated onboarding or wallet acceptance: anchor on eIDAS levels and 2015/1502; plan for wallets at level high.
• UK identity providers and relying parties: DVS trust framework 1.0 with GPG 45 profiles; certification is what puts you on the register.
• Canadian private sector ecosystems: PCTF components relevant to your role, certified through DIACC.
• Multi-country providers: design to the strictest element of each scale (IAL3-style attended route available, AAL3-grade authenticators, eIDAS-grade means lifecycle), then document a per-framework conformance statement. Use ISO/IEC 29115 as the neutral vocabulary in your internal crosswalk.

Small vs large organisations: a small relying party should buy assurance from a certified provider and specify the exact framework and level in the contract; building proofing in-house rarely pays. A large identity provider should maintain one control set and evidence pack, mapped to each framework's clauses, and track revision cycles (NIST rev 4 final in 2025, DVS 1.0 in 2026, ISO/IEC 29115 under revision).

Worked scenario

A fintech serving US and EU customers asks for "AAL2 or eIDAS substantial" for account opening and payments. The team runs DIRM and finds Moderate impact for retail users, so IAL2, AAL2 and FAL2. For EU customers it accepts notified eID means at substantial or wallets at high, rather than building its own route to substantial. It issues device-bound passkeys after onboarding, which meet AAL2 and can support AAL3 where keys are non-exportable. The conformance statement lists, per framework, which component (proofing, authenticator, federation) meets which clause, and where the bank relies on a third party.

Where identity assurance meets non-human identities

None of these frameworks proofs a workload or an AI agent: there is no passport for a service account. What carries over is the authentication and federation thinking. Workload credentials should meet AAL3-like properties (non-exportable keys, phishing-resistant, bound to hardware or a platform identity), and tokens passed between services should carry FAL2-like protections against injection and replay. When an agent acts for a person, the person's assurance level must travel with the delegation, and the agent must not be able to raise it. See the Agent Identity and Access Guide and the NHI Authentication Guide.

Implementing a multi-framework assurance design

1. Inventory requirements: list every customer, regulator and scheme that sets an assurance requirement, with the exact framework, version and level each one names.
2. Run DIRM per user group: record IAL, AAL and FAL separately, then note the eIDAS, GPG 45 or PCTF level each group also needs.
3. Design routes, not one flow: offer separate proofing routes (remote document and biometric, attended, eID or wallet acceptance) and tag each account with the route and level achieved.
4. Pilot with a small cohort: measure completion and fraud rates per route before switching the default, and keep the previous flow available as a rollback.
5. Bind levels into tokens: emit assurance claims in assertions and enforce step-up at the relying party.
6. Certify or attest: obtain the certification each regime expects (DVS conformity assessment, PCTF certification, eIDAS notification or wallet certification) and keep the conformance statement current at each standard revision.

Detection and measurement

• Assurance coverage: share of accounts whose proofing and authenticator levels are recorded as attributes and passed in assertions.
• Level mismatch rate: sessions where the authenticator used is below the level the transaction requires (step-up failures and bypasses).
• Proofing fraud rate: confirmed fraudulent enrolments per 10,000 at each route (remote, attended, eID or wallet).
• Phishing-resistant share: proportion of privileged and high-value users on AAL3-grade authenticators.
• Assertion integrity: rejected assertions for signature, audience or replay failures, monitored for spikes.

Common failure patterns

• Asking for "level 2": without naming the framework and scale, suppliers will pick the cheapest reading.
• Equating login strength with assurance: a strong authenticator on a weakly proofed account is a strong login to an unverified identity.
• Losing the level at federation: assertions that drop the IAL or AAL attribute force relying parties to guess.
• Ignoring recovery: account recovery at a lower level than enrolment silently downgrades the whole account. See the Identity Federation Failure Modes.
• Stale standards references: contracts still citing SP 800-63-3 or the DVS gamma version after their replacements.

Practitioner checklist

• Name the framework, scale and level in every requirement and contract.
• Run NIST DIRM per user group and record IAL, AAL and FAL separately.
• For EU use, check all four 2015/1502 requirement groups, not just authentication.
• Carry assurance attributes in tokens and assertions, and enforce them at the relying party.
• Keep account recovery at or above the enrolment level.
• Maintain an internal crosswalk using ISO/IEC 29115 vocabulary, marked as indicative.
• Require certified providers to state the component, version and level certified.
• Apply AAL3-like and FAL2-like properties to workload and agent credentials.

Standards and references

• NIST: SP 800-63-4 Digital Identity Guidelines
• NIST: SP 800-63-4 Digital Identity Risk Management and assurance levels
• EUR-Lex: Implementing Regulation (EU) 2015/1502 on assurance levels for electronic identification means
• EUR-Lex: Regulation (EU) 2024/1183 establishing the European Digital Identity Framework
• ISO: ISO/IEC 29115:2013 Entity authentication assurance framework
• GOV.UK: UK digital verification services trust framework 1.0
• GOV.UK: How to prove and verify someone's identity (GPG 45)
• DIACC: Pan-Canadian Trust Framework

Related NHI Mgmt Group resources: NIST SP 800-63 Digital Identity Guidelines Guide · eIDAS 2.0 and the European Digital Identity Framework Guide · National Digital ID Schemes Map · Identity Proofing and KYC Guide. This guide summarises identity assurance standards and is not legal advice.