Issuing, Revoking and Replacing Avatier's Identity Challenge Card

An MFA token's lifecycle is everything that happens to it after it exists: it is issued, used, expired or renewed, revoked and replaced. For Avatier's Identity Challenge Card™, a printed three-factor card, Avatier states that "Card issuance, expiration, re-enrollment, and revocation are all logged and policy-enforced."

A hard day in any MFA token's life is the day a worker loses it. How well that day goes depends on decisions made at issuance, long before the card goes missing. For how the card's three factors work at sign-in, see Three-Factor Authentication Explained.

The MFA token lifecycle, in NIST's terms

NIST's authentication guidance, SP 800-63B, treats the lifecycle as its own topic: "Events can occur over the lifetime of a subscriber’s authenticator and affect its use. These events include binding, maintenance, loss, theft, compromise, unauthorized duplication, expiration, and revocation." It also requires that "The record created by the CSP SHALL contain the date and time of significant authenticator life cycle events."

That list works as a checklist for any MFA token, whether it's an app, a key fob or a printed card. Here is each stage next to Avatier's own description of the card:

Stage	NIST's framing	The Identity Challenge Card, in Avatier's words
Issue	Binding means "establishing an association between a specific authenticator and a subscriber account"	"Every card is issued through the existing IGA workflow"
Expire	"When an authenticator expires, it SHALL NOT be usable for authentication."	"Policy-enforced expiration and re-enrollment windows"
Lose	"one must assume that a lost authenticator has been stolen or compromised"	"The card contains no personal data and no identity information."
Revoke	Invalidation is "the removal of the binding between the authenticator and a subscriber account"	"Revocation is immediate — no upstream device cleanup"
Replace	"The replacement of expired authenticators SHALL conform to the binding process"	"revoked in seconds and replaced the same day"

Put together, the stages form a loop rather than a line. A card is issued, used, re-enrolled within policy-enforced windows, and, if it's lost, revoked and replaced, which puts a new card back at the start.

The card's lifecycle as a loop: issue, use, expire or re-enroll, revoke and replace, with every stage logged.

Issuing the card: one IGA workflow for every worker

Avatier's model starts with governance, not hardware: "One IGA workflow provisions cards for every worker. No device procurement, no per-seat app install, no re-enrollment campaign." Workers can enroll themselves, or the organization can "Auto Enroll Everyone at Once."

Each challenge is tied to a person through the identity anchor factor: "The user's directory identity — Employee ID, badge, or SCIM-provisioned principal." Avatier says "Cards are generated and distributed through your existing service desk workflow — users are live within minutes of receiving their card, not weeks of IT onboarding cycles." The card ships in 34 languages, with right-to-left and CJK scripts included.

Two design choices matter later, when a card has to be replaced. First, "No phone number, biometric, or personal data touches the card," and "Card contents are opaque without the user's PIN." Second, Avatier's comparison sets "Per-seat app licenses and hardware procurement" for device-dependent MFA against "Printed once, reissued in seconds at cents per worker" for the card.

Issuance is also where governance gets set up. Avatier lists "Separation of duties between issuer, approver, and auditor" among the card's lifecycle controls, which keeps issuing, approving and auditing as separate roles.

Using, expiring and re-enrolling

In daily use, the card is challenged one coordinate at a time. At login, "The screen types out a coordinate. The worker reads the matching word off the printed grid, then adds the private PIN." At the service desk, "The agent names a coordinate, the caller reads the answer off their printed card, and that value is spent." Avatier states that "Each coordinate value is one-time" and that used values "are permanently burned and never reused."

Expiration is set by policy: "Admins set expiry windows; users receive automated reminders." That fits NIST's advice that "The subscriber SHOULD bind a new or updated authenticator before an existing authenticator’s expiration," so a worker can re-enroll before the old card stops working, not after being locked out.

Re-enrollment is where device-bound tokens add steps. For a software OTP app on a new phone, NIST says the subscriber should "bind the authenticator application on the new device to their subscriber account" and "invalidate the authenticator application that will no longer be used." A printed card has no device to pair. Avatier lists "Easy re-enrollment — no device pairing," and, for service desk leaders, "Re-enrollment in seconds."

When a card is lost: revoke first, then re-issue

NIST's starting assumption is blunt: "Generally, one must assume that a lost authenticator has been stolen or compromised by someone other than the legitimate holder of the authenticator." For physical authenticators, it requires a way to invalidate the authenticator "immediately upon notification from a subscriber that the authenticator’s loss, theft, or compromise is suspected." Compromised authenticators must be invalidated "promptly following compromise detection," and "Organizations SHOULD establish time limits for this process."

In Avatier's account, a lost card carries less risk than a lost phone: "The card contains no personal data and no identity information. Without the PIN it is useless. A lost card is less dangerous than a lost phone — you can't SIM-swap paper." The response should still be the same as for any MFA token. NIST notes that "The consequences of not invalidating a compromised authenticator are usually more significant than the denial-of-service potential of invalidating one in error."

As general guidance, a lost-card runbook comes down to four steps:

1. Report. The worker tells the service desk the card is gone. Publish the reporting path ahead of time, because a worker without a card may also be locked out.
2. Revoke. Revoke the card at once. Avatier says the card "is revoked in seconds," and "Revocation is immediate — no upstream device cleanup."
3. Verify identity. Confirm that the person asking for a new card is the cardholder. Among NIST's account recovery methods is "repeating portions of the identity proofing process." Avatier lists "Identity-verified re-issuance closes the social-engineering path" among the card's lifecycle controls.
4. Re-issue. Bind a new card through the same governed workflow. Avatier says the card is "replaced the same day," and that "every challenge and re-issue lands in the identity governance you already run."

Step 3 is where attackers aim. Avatier's Identity Attack Ledger reviewed 2,242 California breach filings from 1 Jan 2023 to 30 Sep 2026. Of the 53 incidents that name a vector, 12 cite social engineering of a person, a category that "Includes vishing and help-desk pretexting." Avatier notes that "Social engineering attacks target the help desk because knowledge-based verification is guessable." For more on defending the reset desk, see Help Desk Social Engineering Defense.

General guidance for a lost card: report it, revoke it, verify the worker's identity, then re-issue the card the same day.

What Avatier ships toward this pattern

• Identity Challenge Card™ lifecycle controls. Under "Governed issuance, revocation, and audit," Avatier lists issuance through the existing IGA workflow, "Policy-enforced expiration and re-enrollment windows," identity-verified re-issuance and separation of duties. Deployment is "One IGA workflow — full deployment in under an hour." For the product and a live demo, see the Identity Challenge Card.
• Mobile wallets. The card can be added to Apple Wallet, Google Wallet or Samsung Wallet, "alongside the printed card, not instead of it." Government ID verification is coming soon.
• Continuity. In Avatier's framing, the card defines the Identity Continuity Layer; see What Is an Identity Continuity Layer? For workers without a work phone, see MFA for Frontline Workers Without Phones.
• Strong MFA Login. Pillar 5 of Credential Governance™ binds a strong second factor, which can be the Identity Challenge Card, to every password authentication event. For details, see Strong MFA Login.
• The wider platform. For Avatier's AI-native identity platform, see the Avatier Identity Anywhere 2027™ preview. For the full product line, see avatier.com.
• Security posture. Avatier is SOC 2 Type II audited with no exceptions noted and ISO/IEC 27001:2022 certified. For details, see the Avatier Trust Center.