What do organisations get wrong when they treat identity and identification as the same thing?

Why organisations confuse identity with identification

Identity is the enduring subject being represented, while identification is the act of recognising or asserting that subject in a specific context. Organisations often collapse the two because they focus on documents, credentials, or labels as if they were proof in themselves. That creates a false shortcut: the artefact becomes the answer, instead of the process that interprets it.

This mistake matters because an identifier can be correct and still not be trustworthy. The real security question is whether the claim was bound to the right person or system, validated against the right source, and accepted by the right decision process. That distinction is central in digital identity work, where NIST SP 800-63 Digital Identity Guidelines separates proofing, authentication, and federation rather than treating them as one step.

It also shows up in operational systems, where claims are consumed by access decisions, trust policies, transaction rules, and downstream audits. A passport, account name, certificate, or ID token may support identification, but none of them alone proves the full identity relationship the business thinks it has established. The useful lens is always: what is being asserted, by whom, through what mechanism, and with what assurance?

What breaks when paperwork is treated as proof

When organisations treat a document or label as the identity itself, they overvalue static evidence and underweight the controls that actually decide access. That usually leads to weak onboarding checks, brittle exception handling, and a false belief that a single verified artefact remains reliable indefinitely. The problem is not only fraud; it is also drift, where the original claim stops matching the current reality.

The same pattern appears in machine and service contexts, where teams confuse a secret, certificate, or token with the identity it enables. In practice, the important question is whether the system can still trust the claim after rotation, revocation, environment changes, or delegation events. NHIMG’s Ultimate Guide to NHIs is useful here because it ties identity to lifecycle, privilege, and governance rather than to the credential alone.

Once the artefact is mistaken for the identity, control owners often miss the actual failure modes: reused assertions, stale records, overbroad access, and poor offboarding. The organisation believes it has “verified” someone or something when it has really only checked a snapshot. That is why mature identification practice keeps the verifier, the evidence, and the authority path separate.

How to separate identity from identification in practice

The cleanest operational model is to treat identity as the referent, identification as the process, and authentication or authorisation as the decision layer that follows. That means every onboarding, access, or transaction workflow should specify what claim is being accepted, what evidence supports it, and what system is authoritative for the decision. OpenID Connect Core 1.0 is a good example of this separation because it distinguishes identity assertions from the OAuth authorisation layer that carries them.

Practically, organisations should design for three checks: whether the claim is current, whether the source is trusted for this purpose, and whether the relying party is allowed to accept it. That is especially important when identity is reused across systems, because a valid assertion in one context may be meaningless, or even dangerous, in another. Controls work best when they are tied to a transaction boundary, not to a generic label.

For teams building controls, the right measure is not “did we see an ID?” but “did we verify the claim against the right authority and enforce the right access decision?” That viewpoint reduces both false acceptance and false rejection. It also makes audits more meaningful, because evidence can be traced back to the exact process that granted or denied trust.

Risk and Threat Considerations

Conflating identity with identification creates exposure when attackers can present convincing evidence, reuse stale claims, or exploit weak verifier processes. The failure is not usually the document itself, it is the assumption that possession of an artefact equals trustworthy representation.

Failure mechanism: A system accepts a static identifier, token, or document as sufficient proof, even when the claim is unbound, expired, replayed, mis-issued, or accepted by the wrong relying party.

Impact: This can lead to account takeover, unauthorised access, privilege misuse, weak auditability, and persistent trust errors that survive beyond the initial check.

Practitioner Guidance

What to verify: Verify which authority vouches for the claim, what evidence supports it, and whether the verifier is allowed to accept it for the specific transaction. If those three answers are unclear, the control is probably checking the artefact rather than the identity relationship.

Common mistake: Do not let onboarding, access, and audit teams use different meanings for “verified”. If one team means “saw a document” and another means “bound a claim to an authoritative source”, the process will look compliant while still being operationally weak.

Practitioner takeaway: Strong identity practice is not about collecting better proof objects, it is about making each claim testable, context-bound, and authoritative before anything is allowed to rely on it.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they treat compliance frameworks as the same thing?
• What do organisations get wrong when they treat privacy and security as the same thing?
• What do organisations get wrong when they treat identity verification as a pilot project?
• What do organisations get wrong when they treat human, machine, and AI identities the same?