Category: Authentication Factors
Credential
Simply put
A credential is a piece of evidence that establishes who someone is or what authority they hold. In identity systems, it is the object or data that ties a person or system to a claimed identity so that others can trust that association.
Formal definition
A credential is an object or data structure that authoritatively binds an identity, via an identifier, to evidence attesting to a right, authority, or qualification. In IAM contexts, credentials are typically used during authentication to verify a claimed identity, and should be distinguished from the separate steps of identification (asserting an identifier) and authorization (determining permitted actions). The specific form, binding mechanism, and trust properties of a credential vary by deployment and standard; this entry covers the general concept rather than any particular credential type or protocol profile.
Why it matters
The credential is the object on which trust in an identity system ultimately rests. Because a credential authoritatively binds an identity to evidence of a right, authority, or qualification, the security of nearly every downstream decision, whether a principal is allowed to authenticate, and by extension what actions authorization may later grant, depends on the integrity of that binding. A credential that is weak, stolen, improperly issued, or improperly validated undermines the entire chain of trust, regardless of how sound the surrounding access controls may be.
Because a credential is typically presented during authentication to verify a claimed identity, it sits at the boundary where identification (asserting an identifier) is tested against evidence. Confusing this evidentiary role with the separate steps of identification and authorization is a common source of design error: possessing a valid credential establishes who a principal is, not what that principal may do. Keeping these steps distinct is essential when reasoning about how a compromised credential propagates risk through a system.
Who it's relevant to
IAM Engineers
Engineers implementing authentication flows must treat the credential as the evidence tested during authentication, kept distinct from the identifier asserted during identification and from the authorization decisions that follow. The choice of credential form, binding mechanism, and validation logic directly shapes the trust properties of the system.
Security Architects
Architects design the trust chain that a credential anchors. Because so many downstream decisions rest on the integrity of the credential-to-identity binding, architects must reason carefully about how credentials are issued, by which authoritative party, and how their compromise would propagate through the environment.
Identity Governance Leads
Governance leads oversee how credentials are issued and by whom, given that a credential is typically vouched for by a party with authoritative power. Ensuring that issuance is properly controlled and that credentials remain bound to the correct identity over the identity lifecycle is a governance concern distinct from runtime authentication.
Compliance Officers
Compliance officers assess whether credentials serve as adequate, authoritative proof of an identity or qualification and whether their issuance and handling meet applicable requirements. Understanding the credential strictly as evidence attesting to a right or authority, not as an authorization grant, supports accurate control mapping.
Inside Credential
Identifier component
The portion of a credential that names or references the principal being authenticated, such as a username, subject identifier, or key handle. Identification is a distinct step that precedes the verification performed during authentication.
Authenticator (secret or proof)
The element used to prove the claimed identity, drawn from one of the recognized factor categories: knowledge (something known, such as a password or PIN), possession (something held, such as a hardware token or private key), or inherence (something inherent, such as a biometric). A single credential may bind one or more of these.
Cryptographic material
In many modern credentials, key material such as an asymmetric key pair backing the authentication event. In FIDO2/WebAuthn-based credentials, for example, the authenticator holds a private key while the relying party stores the corresponding public key. The specifics vary by credential type and deployment.
Binding and metadata
Information that associates the credential with a principal and governs its use, which may include validity periods, issuer references, and lifecycle state. The exact metadata present depends on the credential type, standard profile, and vendor implementation.
Presentation form
How the credential or its resulting proof is conveyed during an access flow, such as a submitted secret, a signed assertion, or a token issued after successful authentication. Note that a credential used to authenticate is distinct from tokens (for example access, ID, or refresh tokens) subsequently issued.
Common questions
Answers to the questions practitioners most commonly ask about Credential.
Is a credential the same thing as an identity?
No. An identity is the representation of a principal (a user, service, or device) within a system, while a credential is the artifact a principal presents to prove a claim to that identity during authentication. A single identity may be associated with multiple credentials (for example, a password plus a FIDO2 authenticator), and credentials can be issued, rotated, or revoked without changing the underlying identity. Conflating the two tends to obscure lifecycle concerns, since credential management and identity management are typically handled by distinct processes.
Does presenting a credential determine what a principal is allowed to do?
No. Presenting and verifying a credential is part of authentication, which establishes who the principal is. Determining what that principal may do is authorization, a separate step that typically evaluates roles, attributes, or policies after authentication succeeds. A valid credential proves identity but confers no permissions on its own; the two concerns should be kept distinct in any access flow.
How should credentials be stored so they are not exposed if a datastore is compromised?
Practice varies by credential type. Knowledge-factor secrets such as passwords are typically stored as salted, computationally expensive hashes rather than in plaintext or reversibly encrypted form, so that the stored value cannot be reversed to recover the original secret. Possession-factor credentials based on public-key cryptography, such as those used with FIDO2/WebAuthn, avoid storing a reusable shared secret on the server side at all, since the server retains only a public key. The appropriate approach depends on the credential type and your deployment's threat model.
What is the difference between rotating a credential and revoking it?
Rotation replaces an existing credential with a new one while keeping the associated identity active, and is often used on a schedule or after suspected exposure. Revocation invalidates a credential so it can no longer be used for authentication, without necessarily issuing a replacement. Depending on configuration, revocation of self-contained tokens may not take effect until expiry unless an introspection or revocation mechanism is in place, whereas opaque credentials validated against a central store can typically be revoked with more immediate effect.
How do credentials relate to authentication factors in an MFA deployment?
Each credential typically corresponds to a factor drawn from a distinct category: knowledge (something known, such as a password), possession (something held, such as a hardware authenticator), or inherence (something inherent, such as a biometric). MFA requires credentials from two or more different categories, so combining two knowledge secrets does not generally satisfy multi-factor requirements. Whether a given combination qualifies depends on how the categories are defined in the applicable profile or vendor implementation.
How are credentials provisioned and deprovisioned across systems?
Credential lifecycle events are usually part of identity governance and administration (IGA) processes rather than runtime enforcement. In many deployments, account and attribute provisioning is propagated using SCIM, while credential material itself may be established through a separate enrollment step (for example, registering a passkey or setting an initial password). Deprovisioning should ensure that credentials are revoked or disabled when access is no longer authorized; the exact coordination between directory updates, credential invalidation, and downstream systems depends on the specific integration and configuration.
Common misconceptions
A credential and a token are the same thing.
A credential is what a principal presents to prove identity during authentication, whereas tokens such as access tokens, ID tokens, or refresh tokens are typically issued after authentication and carry different purposes. Conflating them blurs the boundary between proving identity and subsequently exercising authorization.
Multi-factor credentials just mean requiring two passwords or two of the same kind of secret.
Genuine MFA requires factors from different categories, typically combining knowledge, possession, and inherence. Two knowledge factors (for example a password plus a security question) generally do not provide the independence that distinct factor types are intended to deliver, and 2FA is a specific two-factor case within MFA.
A signed credential or assertion is also encrypted and therefore confidential.
Signing provides integrity and origin assurance but does not by itself provide confidentiality. Depending on configuration, a signed credential or assertion may still be readable in transit unless it is separately encrypted or protected by transport security.
Best practices
Treat identification, authentication, and authorization as separate steps, and design credential handling so that presenting a credential proves identity without being mistaken for granting entitlements.
Where MFA is used, combine factors from distinct categories (knowledge, possession, inherence) rather than stacking multiple factors of the same type, and consider step-up authentication for higher-risk operations.
Prefer phishing-resistant, cryptographically backed credentials such as those based on FIDO2/WebAuthn where the deployment context supports them, keeping in mind that FIDO2, WebAuthn, and passkeys are related but not interchangeable terms.
Clearly distinguish credentials from issued tokens in your architecture and logging, and validate tokens on their own terms rather than treating token possession as equivalent to a fresh authentication.
Do not rely on signing alone for confidentiality; apply encryption or transport-layer protection when credential or assertion contents must remain private, since a signed artifact is not necessarily an encrypted one.
Manage the full credential lifecycle, including issuance, rotation, and revocation, and document which behaviors depend on vendor, standard profile, or deployment configuration rather than assuming uniform behavior.
