ISO/IEC 24760-2:2025

International
Standard
ISO/IEC 24760-2
Second edition
Information security, cybersecurity
2025-09
and privacy protection —
A framework for identity
management —
Part 2:
Reference architecture and
requirements
Sécurité de l'information, cybersécurité et protection de la vie
privée — Cadre pour la gestion de l'identité —
Partie 2: Architecture de référence et exigences
Horizontal document
Reference number
© ISO/IEC 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 3
5 Reference architecture . 3
5.1 General .3
5.2 Deployment scenarios .3
5.3 Stakeholders .4
5.3.1 General .4
5.3.2 Principal .5
5.3.3 Identity management authority .5
5.3.4 Identity information authority .6
5.3.5 Relying party .6
5.3.6 Regulatory body .6
5.3.7 Consumer/citizen representative or advocate .6
5.4 Actors .7
5.4.1 General .7
5.4.2 Principal .8
5.4.3 Identity management authority .8
5.4.4 Identity registration authority .9
5.4.5 Relying party .10
5.4.6 Identity information authority .10
5.4.7 Identity information provider .11
5.4.8 Verifier . 12
5.4.9 Auditor . 13
5.5 Processes and services . 13
5.5.1 Documentation. 13
5.5.2 Identity information management processes .14
5.5.3 Specific identity information management processes . 15
5.5.4 Additional functions . .17
5.6 Viewpoints . 20
5.6.1 General . 20
5.6.2 Context viewpoint . 20
5.6.3 Functional viewpoint . 20
5.7 Use cases .21
5.7.1 General .21
5.7.2 Principal use cases . 22
5.8 Components . 23
5.8.1 General . 23
5.8.2 Principal . 23
5.8.3 Identity register . 23
5.9 Compliance and governance .24
5.10 Physical model .24
6 Architecture for managing internal identities, the enterprise model .24
6.1 Context .24
6.2 Stakeholders and concerns . 25
6.3 The enterprise deployment scenario . 26
6.4 Use cases . 26
6.4.1 Employee use cases . 26
6.4.2 Employer use cases .27

© ISO/IEC 2025 – All rights reserved
iii
7 Architecture for managing external identities .27
7.1 Context .27
7.2 Stakeholders and concerns .27
7.3 Deployment scenarios with external identities . 29
7.3.1 The federated deployment scenario . 29
7.3.2 The service deployment scenario . 29
7.3.3 The federated deployment scenario as applied as a service . 29
7.4 Use cases . 29
7.4.1 Device use cases . 29
7.4.2 Sharing use cases . 29
8 Requirements for the management of identity information .30
8.1 General . 30
8.2 Access policy for identity information . 30
8.3 Functional requirements for management of identity information . 30
8.3.1 Policy for identity information lifecycle . 30
8.3.2 Conditions and procedure to maintain identity information .31
8.3.3 Identity information interface .31
8.3.4 Reference identifier .31
8.3.5 Identity information quality and compliance . . 33
8.3.6 Archiving information . 33
8.3.7 Terminating and deleting identity information. 33
8.4 Non-functional requirements. 34
Annex A (informative) Use case .35
Annex B (informative) Component model .38
Annex C (informative) Business process model . 41
Bibliography .46

© ISO/IEC 2025 – All rights reserved
iv
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 27, Information security, cybersecurity and privacy protection.
This second edition cancels and replaces the first edition (ISO/IEC 24760-2:2015), which has been technically
revised.
The main changes are as follows:
— in Clause 3, the definitions of terms from ISO/IEC 24760-1 were removed;
— to address the emerging concept of mobile identity, the term “principal’s private IMS” (PPI) was added in
Clauses 3, 4, and described in 5.4.2, 5.4.3 and 5.4.6;
— some of the content of Clause 5 was moved to Clauses 6 and 7;
— former Annex A has been deleted and the existing annexes have been relabelled.
A list of all parts in the ISO/IEC 24760 series can be found on the ISO and IEC websites.
This document has been given the status of a horizontal document in accordance with the ISO/IEC
Directives, Part 1.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2025 – All rights reserved
v
Introduction
Data processing systems commonly gather a range of information on its users, which can include people,
pieces of equipment, or pieces of software connected to the equipment. Based on the information gathered
on user identity, these data processing systems make decisions that can impact how users access to IT
resources.
To address the need to efficiently and effectively implement systems that make identity-based decisions, this
document specifies a framework for the issuance, administration and use of data. This framework serves to
characterize individuals, organizations, or information technology components, which operate on behalf of
individuals or organizations.
For many organizations, the proper management of identity information is crucial for maintaining the
security of the organizational processes. For individuals, correct identity management is important for
protecting privacy.
The ISO/IEC 24760 series specifies fundamental concepts and operational structures for identity
management and provides a framework on which information systems can meet business, contractual,
regulatory, and legal obligations.
This document defines a reference architecture for identity management including interrelationships.
These architectural elements are described in respect to identity management deployments scenarios and
their models. This document also specifies requirements for the design and implementation of an identity
management system so that it can meet the objectives of stakeholders involved in the deployment and
operation of identity management.
This document is intended to provide a foundation for the implementation of other international standards
related to identity information processing such as ISO/IEC 29100, ISO/IEC 29101, ISO/IEC 29115, and
ISO/IEC 29146.
This document is not a management system standard (MSS).

© ISO/IEC 2025 – All rights reserved
vi
International Standard ISO/IEC 24760-2:2025(en)
Information security, cybersecurity and privacy protection —
A framework for identity management —
Part 2:
Reference architecture and requirements
1 Scope
This document:
— provides guidelines for the implementation of systems for the management of identity information;
— specifies requirements for the implementation and operation of a framework for identity management;
— is applicable to any information system where information relating to identity is processed or stored;
— is considered to be a horizontal document for the following reasons:
— it applies concepts such as distinguishing the term “identity” from the term “identifier” on the
implementation of systems for the management of identity information and on the requirements for
the implementation and operation of a framework for identity management,
— it provides an important contribution to assess identity management systems with regard to their
privacy-friendliness and their ability to assure the relevant attributes of an identity, and consequently
it provides a foundation and a common understanding for any other standard addressing identity,
identity information, and identity management.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 24760-1, Information security, cybersecurity and privacy protection — A framework for identity
management — Part 1: Core concepts and terminology
ISO/IEC 29115, Information technology — Security techniques — Entity authentication assurance framework
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 24760-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/

© ISO/IEC 2025 – All rights reserved
3.1
documented design
authoritative description of structural, functional, and operational system aspects
Note 1 to entry: A documented design is the documentation created to serve as guidance for the implementation of an
Information and Communication Technology (ICT) system.
Note 2 to entry: A documented design typically includes the description of a concrete architecture of the ICT system.
3.2
identity management authority
entity responsible for setting and enforcing operational policies for an identity management system
Note 1 to entry: An identity management authority typically commissions the design, implementation, and deployment
of an identity management system.
EXAMPLE The executive management of a company deploying an identity management system in support of its
services.
3.3
invalidation
process performed in an identity management system when a particular attribute is no longer valid for a
particular entity to mark the attribute invalid for future use
Note 1 to entry: Invalidation of attributes can be part of updating the attribute value, for instance, with a change of
address.
Note 2 to entry: Invalidation typically takes place for an attribute that is determined as no longer valid before the end
of a validity period that had previously been associated with it.
Note 3 to entry: The term “revocation” is commonly used for invalidation of attributes that are credentials.
Note 4 to entry: Invalidation typically happens immediately after the determination that an attribute is no longer
valid for a particular entity.
3.4
regulatory body
formally recognized organization tasked and empowered by law, regulation, or agreement to supervise the
operation of identity management systems
3.5
stakeholder
role, position, individual, organization, or classes thereof, having an interest, right, share, or claim, in an
entity of interest
[SOURCE: ISO/IEC/IEEE 42010:2022, 3.17, modified — the Example has been removed.]
3.6
principal’s private identity management system
PPI
identity management system holding identity information for a single principal, operated by, or under
exclusive control of, this principal
Note 1 to entry: The wording “mobile identity” has been used to, among other concepts, refer to a principal’s private
identity management system, e.g. as implemented on a mobile phone or as a dedicated processing token.

© ISO/IEC 2025 – All rights reserved
4 Symbols and abbreviated terms
ICT information and communication technology
IMS identity management system
PII personally identifiable information
PPI principal’s private identity management system
UML unified modeling language
5 Reference architecture
5.1 General
This clause describes the architectural elements for identity management and the relationships between
these elements.
The documented design for the architecture of identity management should be based on ISO/IEC/IEEE 42010
and address the primary concerns of this system, which can be either one or both of the following:
a) managing identity information for the members of an organization (Clause 6);
b) managing identity information for entities outside an organization (Clause 7).
NOTE The reference architecture and architecture description specified in this document are based on
ISO/IEC/IEEE 42010.
The documented design for the architecture of an identity management system should specify the system
in its deployed context based on stakeholders and actors defined in this document. Business-level actors
are stakeholders. Some stakeholders do not interact with the system. The documented design shall address
requirements for both actor and non-actor stakeholders. The documented design shall exhaustively describe
the actors.
A documented design for identity management should use applicable language to describe the reference
architecture; components and functions of this architecture should be labelled according to the terms
defined in the ISO/IEC 24760 series.
This clause provides an overview of the components that can be present in one or more of the architectural
views that can be specified in a documented design including:
— stakeholders (5.3),
— actors (5.4), and
— processes and services (5.5).
Two common viewpoints for identity management are presented in 5.6.
5.2 Deployment scenarios
An identity management system can be deployed according to various scenarios. A deployment scenario
impacts governance of the identity management system. The deployment scenario determines the trust
relationships that exist between parties involved in operating and governing the identity management system.
A deployment scenario can be chosen when extending an existing identity management system. An extension
deployment model can be different from the original or enterprise deployment model.

© ISO/IEC 2025 – All rights reserved
The different deployment scenarios that can be used to implement an identity management system include:
— the enterprise scenario (6.3);
— the federated scenario (7.3.1);
— the service scenario (7.3.2);
— the federated scenario as applied as a service (7.3.3).
5.3 Stakeholders
5.3.1 General
The documented design can recognize the following direct and indirect stakeholders:
— principal,
— identity management authority,
— identity information authority,
— relying party,
— regulatory body,
— auditor,
— assessor,
— cloud service provider, and
— consumer/citizen representative or advocate.
Each stakeholder performs a separate function in the identity management system. These functions imply
specific responsibilities and liabilities.
NOTE 1 The purpose of the deployment of an identity management system, and the regulatory environment of that
deployment, indicates the involvement of stakeholders.
Stakeholders in a particular identity management system can be affiliated with different commercial or
public organizations with their interests in the system shaped by this affiliation. As the information about
the system available to different stakeholders can be different, interactions between stakeholders should be
based on explicitly established trust relations.
The documented design shall specify concrete representations of its stakeholders and actors as defined
in 5.3 and 5.4, respectively. The documented design can add additional stakeholders or actors. It may also
specify the stakeholders and actors identified in 5.3 and 5.4 with multiple distinct representations.
Stakeholders as specified in this document can also be actors. Non-actor stakeholders are a regulatory body
and a consumer/citizen representative or advocate.
Concerns of stakeholders in an identity management system are described in 5.3.2 and 5.3.7 and should be
addressed in the documented design, implementation and operation of the system.
NOTE 2 Concerns expressed for each type of stakeholder are taken into consideration with references when
developing Clauses 6 and 7. The same references can also be used when documenting a reference architecture.

© ISO/IEC 2025 – All rights reserved
5.3.2 Principal
Concerns of a principal in an identity management system include:
— correctness of the identity information collected, processed and stored (can be referenced as “data
correctness”);
— minimization of the identity information collected, processed and stored by the identity management
system (can be referenced as “data minimization”);
— minimization of the identity information usage by the identity management system in its domain of
applicability (can be referenced as “information sharing minimization”);
— ability of different relying parties to correlate identity information for a single principal (can be
referenced as “principal correlation”);
— ability of a relying party to positively link the principal with their recorded identity information received
to identity information that it has already stored, e.g. a user account (can be referenced as “correct
authentication”);
— errors in identification including false negative and false positive identification, and the detection and
handling of errors (can be referenced as “correct identification”);
— knowledge of and consent to, identity information sharing with third parties (can be referenced as
"information and consent”);
— being correctly represented by identity information which is captured, processed or stored (can be
referenced as “representative information”);
— correctness of operations in the delivery of services and the access to resources made available based on
the attributes presented in a specific situation (can be referenced as “correct operation”);
— collecting, processing and storage of identity information only occurs with its informed consent (can be
referenced as “processing consent”),
— equitable treatment in its interactions with the system (can be referenced as “equitable”);
— an easily understandable, effective, appropriate user interface (can be referenced as “understandable”).
NOTE A concern of a principal about how a third-party service uses identity information obtained from the
identity management system is not a concern about the identity management system itself. Therefore, such a concern
is not addressed explicitly in the documented design.
5.3.3 Identity management authority
Concerns of the identity management authority in an identity management system include:
— the definition of identity management objectives for the domain(s) served by the identity management
system (can be referenced as “defined objectives”);
— specification of policies to maintain identity management objectives for the domain(s) served by the
identity management system (can be referenced as “policies specified”);
— fulfilment of the business objectives of the identity management system with respect to principals and
users of identity information (can be referenced as “meeting user objectives”);
— fulfilment of the business objectives of relationships with other identity management (can be referenced
as “meeting third party objectives”);
— accuracy of the identity information provided by each principal as pertaining to that principal and to a
specific level of assurance (can be referenced as “correct information”);
— compliance with regulation (can be referenced as “compliance”).

© ISO/IEC 2025 – All rights reserved
5.3.4 Identity information authority
Concerns of an identity information authority in an identity management system include:
— completeness, correctness and freshness of the identity information (can be referenced as “data quality”);
— meeting requirements from relying parties (can be referenced as “meeting needs of relying parties”);
— effectiveness of the cryptographic methods to assert the identity information (can be referenced as
“appropriate assertion”);
— effectiveness of the cryptographic methods to de-identify the identity information (can be referenced as
“effective de-identification”);
— compliance with regulation (can be referenced as “compliance”); and
— meeting business obligations with principals (can be referenced as “meeting principal objectives”).
5.3.5 Relying party
Concerns of a relying party in an identity management system include:
— confidentiality, availability and integrity, and applicability to a principal of identity information (can be
referenced as “required identity information”);
— provisioning of accurate identity information pertaining to relevant principals at the required level of
assurance (can be referenced as “quality of information”);
— effective, documented and secure interfaces (can be referenced as “usable interfaces”);
— conformance to regulation applicable to its operations (can be referenced as “compliance”);
— effective mechanism and procedures for auditing (can be referenced as “auditing”).
5.3.6 Regulatory body
As an external independent organization, concerns of a regulatory body in an identity management system
include:
— the proper documentation of operating policies (can be referenced as “documented policies”);
— correctness of operation, in particular, in applying operational polices (can be referenced as “correct
operation”);
— proper accountability and audit of system operations (can be referenced as “accountability”);
— compliance of operational policy and operational practice with legal and regulatory requirements (can
be referenced as “compliance”);
— effective reporting on system operations, including control effectiveness, incidents, and actions taken in
overcoming incidents (can be referenced as “effective reporting”);
— effective response to incidents that violate, or have a potential to violate privacy protection (can be
referenced as “incident responsiveness”).
NOTE Effectively, auditors, as actors in an identity management system (see 5.4.9), in inspecting the operations of
an identity management system (see 5.5) can represent the interests of regulatory bodies.
5.3.7 Consumer/citizen representative or advocate
Consumer/citizen advocates are individuals or groups that emerge from civil society and try to protect
consumers and citizens from surveillance, and lobby for improved privacy regulations.

© ISO/IEC 2025 – All rights reserved
Consumer/citizen representatives are individuals appointed by a principal or selected by consumer
organizations to represent a consumer or citizen in its rights with respect to privacy.
The main concerns of consumer/citizen representative and advocates are:
— transparency, notification, compliance and protection against complex legal language (can be referenced
as “clear language”);
— availability of procedures to exercise the rights of consumer/citizen (can be referenced as “accessible
procedures”);
— access of services to disadvantaged populations (can be referenced as “accessible services”).
NOTE 1 Consumer and citizen representatives participate in recognized multi-stakeholder societal processes such
as governance and establish good practices and requirements to be met by those providing goods and services to
consumers and citizens.
NOTE 2 Consumer and citizen representatives are selected, briefed and, where necessary, trained to ensure that
they participate through reasonable and reasoned discussion, based wherever possible on good quality evidence.
5.4 Actors
5.4.1 General
An actor interacts with an identity management system to participate in identity management operations.
An entity may interact with the same identity management system as multiple, different actors. The
document design shall define all interactions by any actor supported by the system.
NOTE 1 Actors can be directly related to the domain that uses an IMS or they can be third parties, which can be
another IMS.
The documented design should describe actor interactions in terms of the functions that the interactions
relate to. Where an actor that interacts with the identity management system requires authentication before
interactions are allowed to proceed, the documented design shall specify the basis for authentication (e.g.
entity-based and role-based authentication), the authentication method and the assurance level required for
each interaction, as defined in ISO/IEC 29115.
NOTE 2 One purpose of specifying actors in the design of an identity management system is to be able to describe
all intended interactions with the system.
A documented design can recognize the following actors:
— principal;
— identity management authority;
— identity registration authority
— relying party;
— identity information provider;
— identity information authority;
— verifier;
— auditor.
The documented design shall specify the level of assurance required to identify and authenticate entities
requesting access to identity information contained in its identity management system, in accordance with
ISO/IEC 29115. The level of assurance can be different for different types of information and the type of
access granted i.e. read, write etc. Authorization can be implemented as specified in ISO/IEC 29146.

© ISO/IEC 2025 – All rights reserved
5.4.2 Principal
A principal is an actor who provides identification information to establish and validate its identity
information within identification management processes. The principal has the following responsibilities:
— to provide accurate identity information for enrolment as a new principal, when applying as an entity to
become registered in a domain of applicability;
— once enrolled as a system user, to request to be recognized by the identity management system and to
be permitted to access services or use resources available in the domain of applicability associated with
the identity management system;
— to facilitate the observation, as the subject of observation to obtain identity information.
NOTE 1 As a subject of observation, the identity information obtained is anonymous until its relation to the
principal has been established.
For a PPI, the principal makes available a suitable hardware platform for the identity register and the
execution environment for implementing IMS functions. A PPI hardware platform can be provided by a
domain where the principal is known, or by a third party. Requirement for this hardware platform and its
operations including issuance and data provisioning are beyond the scope of this document.
NOTE 2 The hardware platform can be a mobile phone in which case the IMS can be an implementation installed on
the phone.
A principal can use an identity management system to:
— request to be recognized by information in the identity management system and to be permitted for
access to services or use of resources available in the domain of applicability associated with the identity
management system, and
— be informed, as a human, of the identity information pertaining to the principle that is held in the identity
management system and to request any errors in the identity information to be corrected.
NOTE 3 In appropriately defined circumstances, a legally authorized representative can act on behalf of a principal.
5.4.3 Identity management authority
An identity management authority is associated with a domain of applicability with the duty and capabilities
to define and adjust business objectives for identity management in that domain and set management
policies to meet these objectives.
NOTE 1 A Chief Information Officer (CIO) in an organization that uses an IMS typically acts as an identity
registration authority. In practice, this can also be realized by a compliance team.
An identity management authority uses policies to regulate the use of registered identity information.
Policies may specify levels of service provided, including the level of assurance on identity information that
can be provided by the identity management system. Policies can also specify how to obtain authorization
for access and modification of identity information in unforeseen circumstances.
The identity management authority shall define identity management objectives for a domain of applicability
served by the identity management system operating under its authority. The identity management authority
shall specify policies to meet identity management objectives for an associated domain.
Responsibilities of an identity management authority include:
— to create, modify or revoke operational policies;
— to ensure legal and regulatory compliance of the policies and operation of the identity management system;
— to require and approve modification of mechanisms to establish a required level of assurance in entity
authentication for access to identity information and system control functions;

© ISO/IEC 2025 – All rights reserved
— to respond to incidents;
— to approve changes in the type of information recorded in the identity register;
— to initiate regular
...