Organisations that trade identities across borders, sectors or suppliers need a shared way to say how much they trust an authentication, and "we use MFA" does not answer that. ISO/IEC 29115 is the international entity authentication assurance framework: it defines four levels of assurance (LoA1 to LoA4), the enrolment, credential management and authentication phases each level must cover, and the threats and controls behind them. This guide explains the structure, what each level requires, how it treats devices and other non-person entities, and how it relates to NIST SP 800-63-4 and the eIDAS assurance levels. It is for identity architects, trust framework designers and assessors who meet LoA language in contracts, procurement or federation agreements. For the US model in depth, see the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.
Key takeaways
- Four levels, one combined score. ISO/IEC 29115 grades the whole chain from enrolment to authentication as LoA1 (low) to LoA4 (very high), and the overall LoA is the lowest level achieved in any phase.
- Still current, revision under way. The 2013 edition was confirmed in 2020 and is marked by ISO as to be revised; ITU-T publishes a similar text as X.1254, whose latest version (09/20) is free to download.
- Multi-factor starts at LoA3. LoA2 accepts single-factor authentication over a secure protocol; LoA3 requires multi-factor; LoA4 adds tamper-resistant hardware for keys.
- Devices are in scope. The framework covers non-person entities such as laptops, phones and smart meters, with trusted hardware such as a TPM expected at LoA3.
- Mappings are approximate. NIST SP 800-63-4 splits assurance into IAL, AAL and FAL, and eIDAS uses low, substantial and high; treat any LoA crosswalk as a starting point for a trust framework, not an equivalence.
What it is and who it applies to
ISO/IEC 29115:2013, Information technology, Security techniques, Entity authentication assurance framework, was published by ISO/IEC JTC 1/SC 27 in April 2013 (edition 1, 36 pages). According to the ISO catalogue page, checked 8 November 2026, it was last reviewed and confirmed in 2020 and is flagged as to be revised. A revision project was at committee draft stage at the time of checking; the content of drafts changes, so this guide describes the 2013 text.
The ITU-T Recommendation X.1254 carries the same framework. Its 2012 version states in the foreword that a similar text is published as ISO/IEC 29115, listing a handful of minor differences. X.1254 was revised in September 2020 and that version is in force and freely downloadable from the ITU-T recommendation page, which makes it the practical way for most teams to read the framework without buying the ISO text.
The standard is voluntary. It applies to anyone who issues or relies on credentials and needs to express assurance in a common way: credential service providers, relying parties, federation operators and the authors of trust frameworks that set specific criteria per level. It deliberately leaves sector criteria to those trust frameworks.
Structure and key requirements
The four levels of assurance
| Level | Name | Confidence in the claimed or asserted identity | Authentication (summary) |
|---|---|---|---|
| LoA1 | Low | Little or no confidence | No specific mechanism; cryptographic methods not required |
| LoA2 | Medium | Some confidence | Single-factor acceptable; control of the credential proven through a secure protocol |
| LoA3 | High | High confidence | Multi-factor required; secrets cryptographically protected in transit and at rest |
| LoA4 | Very high | Very high confidence | As LoA3, plus tamper-resistant hardware for secret and private keys and protection of personal data in the protocol |
The level descriptions are taken from X.1254 (09/2012). The standard says that, apart from multi-factor at LoA3 and LoA4, controls in the authentication phase are chosen based on risk, which leaves room for trust frameworks to be more specific.
The three phases
| Phase | Processes | Main threats named |
|---|---|---|
| Enrolment | Application and initiation, identity proofing, identity information verification, record-keeping; registration usually at the end of enrolment | Impersonation |
| Credential management | Creation (pre-processing, initialisation, binding), issuance, activation, storage, suspension, revocation and destruction, renewal and replacement, record-keeping | Tampering, unauthorised creation, disclosure, unauthorised possession, delayed revocation, use after decommissioning, repudiation |
| Entity authentication | Authentication and record-keeping | Online and offline guessing, credential duplication, phishing, eavesdropping, replay, session hijacking, man-in-the-middle, credential theft, spoofing |
Identity proofing by level
- LoA1: the identity must be unique within the context; a self-asserted identity is acceptable.
- LoA2: the entity must objectively exist, shown with identity information from an authoritative source.
- LoA3: identity information is verified against authoritative sources, with confirmation that the identity is used in other contexts.
- LoA4: multiple authoritative sources and in-person witnessing for human entities.
Management and organisational considerations
An informative clause lists what any credential service provider should be able to show: service establishment, legal and contractual compliance, financial provisions, information security management and audit, external service components, operational infrastructure and measuring operational capability. It sets no per-level criteria here; trust frameworks fill that gap.
Identity and NHI requirements
ISO/IEC 29115 is unusual among assurance frameworks in treating non-person entities (NPEs) explicitly. X.1254 gives laptops, phones, printers and smart meters as examples.
| Level | NPE treatment in the framework | What it means for machine identities today (NHI Mgmt Group interpretation) |
|---|---|---|
| LoA2 | Proofing may include checking a serial number with the manufacturer | Register devices and workloads from an authoritative inventory, not self-registration |
| LoA3 | Trusted hardware such as a TPM shall be used | Hardware-bound keys or attested workload identity rather than static secrets in files |
| LoA4 | Digital certificates may authenticate NPEs; software signed with a LoA4 human-issued credential and counter-signed by the registration authority | Certificate-based identity with an accountable human owner and signed software supply chain |
The credential management threats map directly onto service accounts, API keys and certificates: delayed revocation and use after decommissioning are the same failures as orphaned service accounts and keys left valid after a workload is retired. Practical steps:
- Assign an LoA to each machine credential class: a static API key in a configuration file rarely meets more than LoA2; a TPM-bound or attested key can support LoA3. See the Machine Identity, PKI and Certificate Lifecycle Guide.
- Bind every NHI to a human owner: the LoA4 counter-signing idea is a useful model for ownership and approval. See the Service Account Security Guide.
- Apply the credential management phase to NHIs: creation, activation, suspension, revocation and renewal for keys and tokens, with records. See the NHI lifecycle automation guide.
- Keep records for machines too: the framework expects record-keeping in every phase. For NHIs that means who requested the credential, which workload it is bound to, when it was issued, rotated and revoked, and which systems accepted it, so an investigation can trace use back to an owner.
- Grade AI agents as NPEs: an agent acting on delegated authority is an entity that authenticates; give it its own credential and level rather than letting it reuse a human session. See the Non-Human Identity (NHI) Guide.
Implementation steps
- Inventory relying services and credentials. List each service, the identities (human and machine) that use it and the credential types issued.
- Assess risk per service. Decide the required LoA from the impact of a wrong identity: financial loss, harm, data exposure, regulatory consequences. NHI Mgmt Group suggests recording the reasoning, not only the level.
- Grade each phase separately. Rate enrolment, credential management and authentication for each credential type; the overall LoA is the lowest of the three.
- Close the weakest phase first. A strong authenticator issued after weak enrolment still gives a low overall LoA. Typical fixes are authoritative-source proofing, faster revocation and record-keeping.
- Set authentication controls per level. Multi-factor at LoA3 and above; hardware-protected keys at LoA4; phishing-resistant methods where your risk assessment calls for them. See the Phishing-Resistant MFA Guide.
- Write the trust framework criteria. If you federate with partners, document concrete criteria per level in agreements, since the standard leaves them open.
- Pilot and test. Run one service at the target LoA, test step-up when a lower-assurance credential requests a higher-assurance action, and keep the previous flow available as rollback until metrics are stable.
- Review on change. Reassess when a new credential type, proofing method or federation partner is added, and when the revised standard is published.
Choosing a framework and a level
| Situation | Suggested approach (NHI Mgmt Group view) |
|---|---|
| US federal systems or suppliers to US agencies | Use NIST SP 800-63-4 IAL, AAL and FAL as the primary model; keep 29115 only for international partners |
| EU public services or notified eID schemes | Use eIDAS low, substantial and high with Implementing Regulation 2015/1502 criteria |
| Cross-border or multi-sector federation with no regulator-set model | Use 29115 as the shared vocabulary and write explicit criteria per level in the trust framework |
| Internal workforce access only | Use whichever model your auditors already recognise; 29115 is useful for grading device and service credentials alongside staff |
- Small organisations: pick two target levels (for example LoA2 for low-risk services and LoA3 for anything administrative or financial) rather than four, and spend effort on revocation and record-keeping.
- Large organisations and federations: publish a level per service in a catalogue, require partners to state their level and criteria in onboarding, and test step-up across federation boundaries.
- Trade-off: a higher LoA reduces impersonation risk but raises enrolment friction and support cost; LoA4 in-person witnessing is rarely justified outside high-impact services.
Evidence and assessment
| Phase | Evidence an assessor will expect |
|---|---|
| Enrolment | Proofing procedure per level, list of authoritative sources, records of evidence checked, in-person witnessing records at LoA4 |
| Credential management | Issuance and activation records, binding method, revocation turnaround, renewal policy, storage protections |
| Authentication | Authenticator types per level, protocol protections, authentication logs, failed attempt handling |
| Management and organisation | Contracts, audit reports, ISMS evidence, management of external service components |
Metrics that show the scheme is working:
- Percentage of services with a documented required LoA.
- Percentage of credentials (human and machine) meeting the LoA of the services they access.
- Median time from revocation request to credential being unusable.
- Number of credentials active after their entity was decommissioned.
- Step-up success and failure rates for higher-assurance actions.
Mapping to other frameworks
The table below is an indicative crosswalk by NHI Mgmt Group, not an official equivalence. The underlying models differ, so always check the specific criteria.
| ISO/IEC 29115 | NIST SP 800-63-4 (closest) | eIDAS (closest) |
|---|---|---|
| LoA1 Low | No proofing; AAL1 | Below or at low |
| LoA2 Medium | IAL1; AAL1 | Low |
| LoA3 High | IAL2; AAL2 | Substantial |
| LoA4 Very high | IAL3; AAL3 | High |
- NIST SP 800-63-4: the Digital Identity Guidelines (final, 31 July 2025) separate identity proofing (IAL1 to IAL3), authentication (AAL1 to AAL3) and federation (FAL1 to FAL3), rather than one combined level. AAL2 requires two distinct factors and AAL3 requires phishing resistance with a non-exportable private key, which is stricter on phishing than LoA3 or LoA4 wording. See the NIST SP 800-63 Digital Identity Guidelines Guide.
- eIDAS: Article 8 of Regulation (EU) No 910/2014 defines low, substantial and high. Implementing Regulation (EU) 2015/1502 sets the criteria under enrolment, electronic identification means management, authentication, and management and organisation, a structure close to 29115. Its recital 3 says ISO/IEC 29115 was taken into account as the principal international reference but that the Regulation differs, especially on identity proofing and verification. Substantial requires dynamic authentication. See the eIDAS 2.0 and the European Digital Identity Framework Guide.
- NIST SP 800-53 Rev 5 and CSF 2.0: IA-2 (organisational users), IA-3 (devices), IA-5 (authenticator management), IA-8 (non-organisational users), IA-9 (services) and IA-12 (identity proofing); CSF PR.AA-01, PR.AA-02 and PR.AA-03.
- ISO/IEC 27001:2022: the Annex A controls on identity management, authentication information and secure authentication.
- ISO/IEC 24760: the identity management framework uses 29115 for authentication assurance. See the ISO/IEC 24760 guide.
Common pitfalls
- Grading only the authenticator. A hardware token issued after a phone call with no proofing is not LoA3 or LoA4; the weakest phase sets the level.
- Treating crosswalks as equivalence. Accepting a partner's "LoA3" as AAL2 or eIDAS substantial without checking criteria, especially phishing resistance and proofing.
- Forgetting revocation. Credential management threats such as delayed revocation and use after decommissioning are where many real compromises start, for humans and machines alike.
- Leaving machines out. Assigning LoA to staff accounts while service accounts and API keys sit outside the scheme.
- Citing an unreadable standard. Contracts that require "ISO 29115 LoA3" without stating criteria or which edition; refer to the edition and add explicit criteria.
- Ignoring the revision. The standard is flagged for revision; plan a review when the new edition appears.
Practitioner checklist
- Read X.1254 (09/20) or ISO/IEC 29115:2013 and record which text your policies cite.
- Assign a required LoA to every relying service, with documented risk reasoning.
- Grade enrolment, credential management and authentication separately for each credential type.
- Require multi-factor at LoA3 and hardware-protected keys at LoA4.
- Bring devices, workloads and service accounts into the scheme with owners and LoA ratings.
- Measure revocation time and credentials active after decommissioning.
- Write explicit criteria into federation and supplier agreements rather than citing a level alone.
- Keep an indicative crosswalk to NIST SP 800-63-4 and eIDAS, reviewed when either changes.
Standards and references
- ISO: ISO/IEC 29115:2013 Entity authentication assurance framework
- ITU-T: X.1254 Entity authentication assurance framework
- NIST: SP 800-63-4 Digital Identity Guidelines
- NIST: SP 800-63-4 assurance levels and digital identity model
- EUR-Lex: Commission Implementing Regulation (EU) 2015/1502 on assurance levels
- EUR-Lex: Regulation (EU) No 910/2014 (eIDAS), consolidated text
- ISO: ISO/IEC 24760-2:2025 Reference architecture and requirements
Related NHI Mgmt Group resources: NIST SP 800-63B-4 Authenticator Assurance Levels Guide · NIST SP 800-63A-4 Identity Proofing (IAL) Guide · eIDAS 2.0 and the European Digital Identity Framework Guide · ISO/IEC 24760 · MFA Guide