Identity programmes stall when teams, auditors and suppliers use "identity", "account", "identifier" and "credential" to mean different things, and when nobody can say which part of the system owns which piece of identity information. ISO/IEC 24760 is the international framework for identity management: Part 1 fixes the core concepts and terminology, Part 2 gives a reference architecture and requirements, and Part 3 sets out practice and controls. All three parts were republished as new editions in September 2025. This guide explains what each part covers, how its concepts apply to people, devices, software and AI agents, how to use it to structure an identity programme, and how it maps to the ISO/IEC 27001:2022 identity management control and NIST SP 800-63-4. It is for identity architects, IAM and IGA leads, and auditors who want a vendor-neutral vocabulary and model. For the basics of IAM and IGA, see IAM and IGA Basics.
Key takeaways
- Three parts, refreshed in 2025. ISO/IEC 24760-1:2025 (core concepts and terminology, edition 3), 24760-2:2025 (reference architecture and requirements, edition 2) and 24760-3:2025 (practice, edition 2) replace the 2019, 2015 and 2016 editions and their 2023 amendments.
- An identity is a set of attributes, not a person. One entity can have many identities in different domains, and an identifier only needs to be unique within its domain; this distinction is what makes the model work for machines.
- Entities include devices and software. The 2025 editions apply to individuals, organisations, devices and software, so service accounts, workloads and AI agents fit the same model as staff.
- It is a framework, not a certification. There is no 24760 certificate; use it to define terms, structure an architecture and choose controls, and evidence those through ISO/IEC 27001 or other audits.
- It links the identity standards family. 24760 points to ISO/IEC 29115 for authentication assurance, ISO/IEC 29100 for privacy and ISO/IEC 29146 for access management.
What it is and who it applies to
ISO/IEC 24760 is published by ISO/IEC JTC 1/SC 27 under the series title Information security, cybersecurity and privacy protection, A framework for identity management. The ISO catalogue, checked 8 November 2026, lists all three current parts as published in September 2025:
| Part | Current edition | What it covers | Replaces |
|---|---|---|---|
| 24760-1:2025 Core concepts and terminology | Edition 3, 2025-09 | Terms and concepts (identity, identifier, attribute, credential and their relationships); the foundational part of the series | 24760-1:2019 and Amd 1:2023 |
| 24760-2:2025 Reference architecture and requirements | Edition 2, 2025-09 | Components, functions and interactions of an identity management system; privacy and mobile identity concepts such as the principal's private IMS | 24760-2:2015 |
| 24760-3:2025 Practice | Edition 2, 2025-09 | Guidance and controls for managing identity information; attribute-based access control; assurance; mobile and decentralised identity | 24760-3:2016 and Amd 1:2023 |
The standard applies to any information system that processes identity information. It is voluntary and horizontal: it does not target a sector, and it sets no assurance levels of its own. Organisations use it in three ways: as a shared glossary in policies and contracts, as a reference architecture when designing or reviewing identity platforms, and as a control catalogue for managing identity information. Be careful with older material: many articles and training courses still quote the 2011 or 2019 wording.
Structure and key requirements
Part 1: core concepts
The clause structure of 24760-1:2025 runs from identity (identity information, identifier, credential), through attributes, managing identity information and the identity lifecycle, to identification, authentication, maintenance, implementation aspects and privacy. The key terms, in paraphrase:
| Term | Meaning in 24760-1 (paraphrased) | Practical reading |
|---|---|---|
| Entity | Something that has a separate existence and can be identified | A person, organisation, device, workload, service or agent |
| Identity | A set of attributes related to an entity; an entity can have several identities | Your directory record, your HR record and your cloud principal are different identities of one person |
| Attribute | A characteristic or property of an entity | Name, department, workload namespace, owner, risk tier |
| Identifier | Attribute or attributes that uniquely distinguish an identity within a domain | Employee number, UPN, client ID, SPIFFE ID |
| Credential | A representation of an identity used for authentication | Password, passkey, certificate, token, API key |
| Identity information authority (IIA) | Entity related to a domain that can make verifiable statements about attribute values | HR system for employment status, CMDB or cloud control plane for workload attributes |
| Enrolment and registration | Making an entity known in a domain: collecting and validating identity information, then recording it in an identity register | Joiner process for staff; creation of a service account with owner and purpose |
| Verification | Confirming that identity information associated with an entity is correct | Proofing a new hire, attesting a workload |
The identity lifecycle
Part 1 covers identity lifecycle management, enrolment and registration, identity proofing, authentication and maintenance. NHI Mgmt Group reads it as a practical lifecycle with these stages, applied equally to human and machine identities:
- Enrolment: collect and verify identity information against an identity information authority, then register it.
- Active use: issue credentials, authenticate and supply attributes to relying parties.
- Maintenance: update attributes when circumstances change (mover events, workload redeployment), and re-verify where needed.
- Suspension: temporarily stop use without losing the record.
- Archiving or deletion: end use, keep only what retention and audit require, and prevent identifier reuse where that could cause confusion.
See the Joiner-Mover-Leaver Guide for the workforce process.
Part 2: reference architecture
Part 2 defines the reference architecture and system requirements for an identity management system (IMS): the components, functions and interactions needed for identities of individuals, organisations, devices and software. The 2025 edition refines the architecture, adds privacy and mobile identity concepts, including a principal's private IMS such as a wallet, and aligns with ISO/IEC 29100, 29115 and 29146. Use it to check that each architectural role in your estate (identity register, identity information authority, credential issuer, verifier, relying party) has a named system and owner.
The mobile and decentralised identity material is the main reason to revisit an older 24760 mapping. Where users hold credentials in a wallet and present selected attributes, the holder's device becomes part of the identity management system, and the relying party must decide which issuers it accepts as identity information authorities. Part 3 Annex B on attribute-based credentials supports the same privacy goal of disclosing only the attributes a service needs. See the Digital Identity Wallets Guide.
Part 3: practice and controls
| Part 3 clause | Topic | What to do with it |
|---|---|---|
| 5 | Mitigating identity related risk: risk assessment, assurance in identity information (identity proofing, credentials, identity profile) | Set proofing and credential strength by risk; use ISO/IEC 29115 levels where you need a scale |
| 6 | Identity information and identifiers: access policy, identifier categories and management | Write a policy on who may read identity data; define identifier formats and reuse rules per entity type |
| 7 | Auditing identity information usage | Log access to and changes of identity information |
| 8 | Control objectives and controls: establishing an IMS, establishing and managing identity information, architectural controls | Use as a checklist for your IAM control set |
| Annex A and B | Federation practice; attribute-based credentials for privacy | Federation agreements and selective disclosure designs |
Identity and NHI requirements
Because the 2025 editions explicitly cover devices and software, 24760 gives a neutral, standards-backed vocabulary for non-human identities. That is useful when a programme has to justify why service accounts and API keys need the same governance as staff accounts.
- Every NHI is an identity in a domain: a workload may have a cloud principal, a Kubernetes service account and a certificate, each an identity with its own identifier. Inventory them as linked identities of one entity, not as unrelated secrets. See the Non-Human Identity (NHI) Guide.
- Name an identity information authority for machines: for staff it is HR; for workloads it should be the deployment platform or CMDB that knows the workload exists, its owner and its environment.
- Enrol, do not just create: registration of an NHI should capture owner, purpose, environment and expiry, mirroring human enrolment.
- Maintain and retire: mover and leaver events for machines are redeployments and decommissions; credentials must follow. See the NHI lifecycle automation guide.
- Identifier management: Part 3 categorises identifiers by type of entity and method of value creation; for NHIs define formats (for example SPIFFE IDs or naming conventions) and forbid reuse of a retired identifier for a new workload.
- AI agents: treat an agent as software with its own identity and attributes (owner, delegated scope, model, environment), not as an extension of the user who launched it.
Implementation steps
- Adopt the vocabulary. Add 24760-1 definitions to your identity policy glossary and use them consistently in standards, contracts and tooling requirements.
- Map your architecture. For each 24760-2 role, record the system that performs it and its owner, including for workload and device identities. Gaps and duplicates become visible quickly.
- Name the authorities. List the identity information authority for each attribute that drives access (employment status, department, workload owner, environment).
- Define the lifecycle per entity type. Write enrolment, maintenance, suspension and retirement steps for employees, contractors, partners, devices, workloads and agents. See the Contractor Identity Lifecycle Guide.
- Set assurance by risk. Use Part 3 clause 5 with a scale from ISO/IEC 29115 or NIST SP 800-63-4. See the ISO/IEC 29115 guide.
- Select controls. Compare your control set to Part 3 clause 8 and record gaps in your risk register.
- Pilot. Apply the model to one domain (for example cloud workloads in one account) and measure inventory completeness and owner coverage before expanding.
- Embed in audit. Reference 24760 terms and controls in your ISO/IEC 27001 Statement of Applicability justification for the identity management control.
Small and large organisations
- Small: use Part 1 terminology and a one-page lifecycle per entity type; buy Part 3 only if you need a control checklist.
- Large or federated: use Part 2 to define roles across business units and partners, and Part 3 Annex A for federation practice.
Evidence and assessment
There is no certification against 24760, so evidence is shown through your ISMS and identity audits.
| Area | Evidence |
|---|---|
| Terminology | Policy glossary aligned to 24760-1 |
| Architecture | Role-to-system map with owners, including NHI domains |
| Authorities | Register of identity information authorities per attribute |
| Lifecycle | Documented enrolment, maintenance and retirement procedures with samples of completed events |
| Identifiers | Identifier format and reuse rules per entity type |
| Auditing | Logs of access to and changes of identity information |
Useful metrics:
- Percentage of identities (human and machine) with a registered owner.
- Percentage of access-driving attributes sourced from a named authority.
- Median time from leaver or decommission event to credential revocation.
- Number of orphaned identities found per review cycle.
- Percentage of entity types with a documented lifecycle.
Mapping to other frameworks
| Framework | Where 24760 helps |
|---|---|
| ISO/IEC 27001:2022 Annex A | Identity management control (full lifecycle of identities); also the authentication information and access rights controls |
| NIST SP 800-63-4 | Its subscriber account, CSP, verifier and relying party roles line up with 24760 enrolment, registration and verification; assurance levels come from IAL, AAL and FAL |
| NIST SP 800-53 Rev 5 | AC-2 account management, IA-4 identifier management, IA-5 authenticator management, IA-12 identity proofing |
| NIST CSF 2.0 | PR.AA-01 identities and credentials managed; PR.AA-02 identities proofed and bound to credentials |
| ISO/IEC 29115 | Authentication assurance levels referenced by Part 2 and Part 3 |
| ISO/IEC 29100 and 29146 | Privacy framework and access management framework in the same family |
The NIST Digital Identity Guidelines SP 800-63-4 were published as final on 31 July 2025. They describe applicants becoming subscribers after proofing and enrolment, with a credential service provider binding authenticators to a subscriber account; that maps closely to 24760 enrolment and registration. NIST's model is written for people, so use 24760 for the device and software side. See the NIST SP 800-63 Digital Identity Guidelines Guide and the ISO 27001 Certification Guide.
Common pitfalls
- Quoting withdrawn editions. Policies citing 24760-1:2019 definitions after the 2025 edition; reference the current edition and review wording.
- Treating identity as account. Counting accounts rather than identities hides that one person or workload has many identities across domains.
- No authority for machine attributes. Workload owner and environment typed by hand into a ticket rather than taken from the deployment platform.
- Lifecycle for staff only. Joiner and leaver processes with no equivalent for service accounts, devices and agents, leaving orphaned credentials.
- Claiming 24760 compliance. There is no certification; claim alignment and show evidence through your audit regime.
- Identifier reuse. Reassigning a retired username or client ID, so old logs and grants attach to the wrong entity.
Practitioner checklist
- Confirm your policies cite 24760-1:2025, 24760-2:2025 and 24760-3:2025.
- Align the identity policy glossary with 24760-1 terms.
- Map each 24760-2 architectural role to a system and owner, including NHI domains.
- Name an identity information authority for every access-driving attribute.
- Document the lifecycle for each entity type, including workloads and AI agents.
- Set identifier formats and forbid reuse of retired identifiers.
- Choose an assurance scale (ISO/IEC 29115 or NIST SP 800-63-4) and apply it by risk.
- Reference 24760 in the identity management control justification of your Statement of Applicability.
Standards and references
- ISO: ISO/IEC 24760-1:2025 Core concepts and terminology
- ISO: ISO/IEC 24760-2:2025 Reference architecture and requirements
- ISO: ISO/IEC 24760-3:2025 Practice
- ISO: ISO/IEC 29115:2013 Entity authentication assurance framework
- NIST: SP 800-63-4 Digital Identity Guidelines
- NIST: SP 800-63-4 digital identity model
Related NHI Mgmt Group resources: IAM and IGA Basics · Joiner-Mover-Leaver Guide · ISO/IEC 29115 · Non-Human Identity (NHI) Guide · ISO 27001 Certification Guide