Digital identity

ISO/IEC 24760-1, the framework standard for identity management, defines an identity as a set of attributes related to an entity, and an identifier as one or more attributes that uniquely distinguish that entity within a domain. Two consequences follow. An identity is always relative to a context: the same person is one identity in the payroll system, another in a partner's portal and a third as a MitID user. And the entity itself is never in the system, only claims about it, which is why identity proofing and authentication exist as separate steps.

Identifier design is where many bugs start. Robust systems key accounts on immutable, never-reassigned identifiers, such as a Windows SID, an Entra object ID or, in OpenID Connect, the pair of issuer and sub claim, which is guaranteed unique and stable only in combination. Mutable attributes such as email addresses, user principal names or display names change with marriage, reorganisation or domain migration, and are sometimes reassigned to a new person; using them as the primary key leads to account takeover or orphaned data. National identifiers such as the Danish CPR number are convenient but are personal data whose processing is specifically regulated (section 11 of the Danish Data Protection Act), so they should not be used as a general-purpose login name.

How strongly an identity is established is a separate dimension from how strongly it is authenticated later. NIST SP 800-63A defines identity assurance levels (IAL1 to IAL3) built from resolution, validation of evidence and verification that the applicant is the owner of that evidence. In the EU, the eIDAS Regulation (EU) No 910/2014, Article 8, defines the assurance levels low, substantial and high for notified electronic identification schemes, and its 2024 amendment, Regulation (EU) 2024/1183, obliges member states to offer European Digital Identity Wallets that hold verifiable attributes under the user's control.

Identities are not only human. Devices, workloads, service accounts and AI agents all need identities, and in cloud estates non-human identities typically far outnumber people. Frameworks such as SPIFFE give workloads URI identifiers (spiffe://trust-domain/path) backed by short-lived certificates or JWTs. Identity governance ties the pieces together: one identity, sourced from HR or a registry, fans out to many accounts, each with credentials and permissions, and deprovisioning the identity should cascade to all of them. Confusing the layers, for example treating an email address as the person, is a root cause of both access creep and audit gaps.