Skip to main content
Commerce Security Authority
Category: Authentication Methods

Authenticator

Also known as: authentication factor, authenticator app
Simply put

An authenticator is something a person uses to prove who they are when signing in to a system or account. It can be a physical item you possess, such as a card or a phone running an authenticator app, or a factor like a fingerprint or a PIN. It is one piece of confirming identity and does not by itself guarantee that a login or transaction is legitimate.

Formal definition

An authenticator is a means used to perform digital authentication by confirming a claimed identity. It may take the form of something the claimant possesses and controls (for example, a hardware token, PIV Card or derived credential, or a software-based authenticator such as an app implementing time-based one-time passwords), something the claimant knows (a password or PIN), or something the claimant is (a biometric). Authenticators are the components that supply one or more authentication factors; combining factors from distinct categories is what constitutes multi-factor authentication (MFA), and a single authenticator alone should not be treated as equivalent to MFA. Within payment contexts, note that an authenticator supports identity verification for access to systems and accounts and is distinct from transaction-level controls such as EMV chip authentication, 3-D Secure, and strong customer authentication, which address different risks at different points in a transaction. Implementations vary; the security properties of a given authenticator depend on its type, protection of secrets, and binding to the identity, not on the label alone.

Why it matters

Authenticators are the practical mechanism by which access to systems, applications, and accounts is controlled, and the strength of that access control depends heavily on the type of authenticator used and how its secrets are protected. A password or PIN alone is a single authenticator supplying a single factor; treating one authenticator as if it were multi-factor authentication is a common misunderstanding that can leave accounts exposed to credential theft, phishing, and reuse attacks. Combining authenticators from distinct categories—something you know, something you possess, and something you are—is what constitutes MFA, and this distinction matters when evaluating whether an access control meets a stated requirement.

In payment environments, it is important to keep authenticators in the right conceptual place. An authenticator supports identity verification for access to systems and accounts, and this is a different concern from transaction-level controls such as EMV chip authentication, 3-D Secure, and strong customer authentication, which address different risks at different points in a transaction. Confusing account-access authentication with transaction authentication can lead teams to assume a control covers a risk it was never designed to address.

No single authenticator guarantees that a login or transaction is legitimate. Its security properties depend on its type, the protection of its underlying secrets, and how well it is bound to the claimed identity—not on the product name or label. Evaluating authenticators on these properties, rather than assuming equivalence across implementations, is what allows security and compliance teams to reason accurately about the assurance a given control actually provides.

Who it's relevant to

Security engineers and architects
Those designing access controls need to distinguish a single authenticator from true multi-factor authentication, and to evaluate authenticators on their type, secret protection, and identity binding rather than on the product name. This informs choices between passwords, PINs, hardware tokens, software authenticator apps, and biometrics for system and account access.
Compliance officers
Compliance teams assessing whether access controls meet stated MFA requirements must confirm that factors come from distinct categories and that a single authenticator is not being counted as multi-factor. They should also keep authenticator-based account access conceptually separate from transaction-level controls.
Payment processors and acquirers
Teams working across payment flows should recognize that an authenticator supports identity verification for access to systems and accounts and is distinct from transaction-level controls such as EMV chip authentication, 3-D Secure, and strong customer authentication, which address different risks at different points in a transaction.
Fraud analysts and merchant risk teams
Analysts evaluating account security should understand that no single authenticator guarantees a login is legitimate; its effectiveness depends on implementation and on the protection of its secrets. This context helps set realistic expectations for what account authentication does and does not cover.

Inside Authenticator

Authentication factor categories
An authenticator falls into one of the recognized factor types: something you know (such as a password or PIN), something you have (such as a token, smart card, or cryptographic device), or something you are (a biometric characteristic). Combining factors from different categories is what constitutes multi-factor authentication.
Knowledge-based authenticators
Secrets such as passwords, passphrases, or PINs. In payment contexts, a PIN and its associated PIN block are subject to specific handling requirements; note that PIN protection is addressed by PCI PIN rather than being solely a PCI DSS matter, and PINs are treated as sensitive authentication data that must not be stored after authorization.
Possession-based authenticators
Physical or logical objects the user holds, such as hardware tokens, one-time-password generators, smart cards, or cryptographic keys on a device. EMV chip authentication relies on a possession element in the card, but chip authentication addresses card-present transaction integrity and is distinct from an access-control authenticator used to log into systems.
Inherence-based (biometric) authenticators
Characteristics measured from the user, such as fingerprint or facial data. Biometric matching is probabilistic and carries false-accept and false-reject trade-offs; it is intended to help verify identity but does not guarantee a correct match.
Authenticator lifecycle elements
Issuance, binding to an identity, storage or protection of the underlying secret or credential, rotation or replacement, and revocation. How these are managed affects whether an authenticator meaningfully supports access control requirements.
Relationship to distinct standards and controls
Authenticators used to protect access to systems that handle account data fall under PCI DSS access-control expectations, whose exact requirement numbering and wording differ between versions and should be confirmed against the current published standard. Authenticators are separate from 3-D Secure and strong customer authentication, which authenticate a payer during a transaction rather than authenticating a user's access to an environment.

Common questions

Answers to the questions practitioners most commonly ask about Authenticator.

Is an authenticator the same thing as a password?
No. A password is one type of authenticator, but the term is broader. An authenticator is any factor a user presents to prove an asserted identity, which may be something you know (a password or PIN), something you have (a token, smart card, or cryptographic device), or something you are (a biometric). Treating authenticator and password as synonyms obscures the distinction between single-factor and multi-factor approaches, and it can lead teams to overlook non-knowledge factors when designing access controls.
Does using an authenticator by itself mean I have multi-factor authentication?
Not necessarily. Multi-factor authentication requires two or more authenticators drawn from different factor categories (knowledge, possession, and inherence). Presenting two authenticators of the same type, such as a password and a security question, is not multi-factor because both are knowledge factors. The presence of an authenticator alone tells you nothing about how many independent factors are involved or whether they are genuinely independent.
How should authenticators be handled to align with PCI DSS access control expectations?
PCI DSS addresses authentication of user and administrative access to system components in and connected to the cardholder data environment, including expectations around authenticator strength, protection, and multi-factor authentication for certain access. The specific requirement numbering and wording differ between PCI DSS versions, so confirm the applicable controls against the current published standard rather than relying on a fixed requirement number. Note that PCI PIN and related standards govern PIN and PIN-block handling in payment transactions, which is a separate matter from user authenticators for system access.
How should authenticators be stored and transmitted?
Authenticators such as passwords should be protected in a manner appropriate to the factor, for example by storing them using strong one-way cryptographic methods rather than in recoverable form, and by protecting them in transit. The suitable protection depends on the authenticator type; a possession-based cryptographic device is protected differently than a knowledge factor. Confirm the specific protection expectations against the current published standard governing the environment in question.
What is the difference between an authenticator used for system access and authentication data in a payment transaction?
An authenticator for system access proves the identity of a user or administrator to a system component. Authentication data in a payment transaction, such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks, is sensitive authentication data tied to the payment itself and must not be stored after authorization even if encrypted. These are distinct concepts; do not conflate a user login credential with the sensitive authentication data associated with a card transaction.
Does deploying stronger authenticators eliminate account takeover or fraud?
No. Stronger authenticators, including multi-factor authentication, are intended to help reduce the risk of unauthorized access and may mitigate certain account takeover techniques, but they do not eliminate fraud. Attackers may target enrollment and recovery flows, use social engineering, or exploit implementation weaknesses, and detection controls involve false-positive and false-negative trade-offs. Authenticators address one point in an access or transaction flow and should be combined with other controls rather than treated as a complete safeguard.

Common misconceptions

Multi-factor authentication means using two passwords or two secrets.
Multi-factor authentication requires factors drawn from different categories — knowledge, possession, and inherence. Two knowledge-based secrets, such as a password plus a security question, are the same factor type and do not constitute multi-factor authentication.
A strong authenticator eliminates fraud or unauthorized access.
Authenticators are intended to help reduce unauthorized access at a specific point, but they address only one part of the risk picture. They do not by themselves stop account takeover, phishing that harvests credentials, or transaction-level fraud, and detection and biometric controls carry false-positive and false-negative trade-offs.
EMV chip authentication, 3-D Secure, and login authenticators are interchangeable.
These operate at different points and against different risks. EMV chip authentication supports card-present integrity, 3-D Secure and strong customer authentication verify a payer in card-not-present or applicable flows, and access authenticators verify a user logging into a system. Using one does not satisfy the purpose of another.

Best practices

Combine authenticators from genuinely different factor categories when multi-factor authentication is required, and verify the implementation rather than relying on the label.
Treat PINs, PIN blocks, and other sensitive authentication data as data that must not be stored after authorization, even in encrypted form, and confirm PIN handling against PCI PIN where applicable.
Map access-control authenticator requirements to the current published version of PCI DSS, confirming exact requirement wording and numbering rather than assuming a fixed reference.
Manage the full authenticator lifecycle, including secure issuance, protection of stored secrets, rotation, and prompt revocation when credentials are compromised or personnel change.
When using biometric authenticators, account for false-accept and false-reject trade-offs and provide a documented fallback method rather than treating a match as definitive.
Do not rely on a single authenticator or transaction-authentication mechanism to address fraud broadly; layer access authentication with transaction-level controls such as 3-D Secure or strong customer authentication where relevant, recognizing each addresses a different risk.