What Is an Identity Continuity Layer? Authentication When Devices Fail

An Identity Continuity Layer is an infrastructure layer that ensures authentication persists when device-dependent systems fail. It gives every worker a way to prove who they are when the phone is lost, the battery is dead, there's no signal, or the device on the counter belongs to the whole shift, without sending that worker to a help desk that has to take their word for it.

Avatier coined the term to name the category the Identity Challenge Card™ defines. The card is a printed grid of word pairs, with no phone, no app, and no network involved. A worker reads back a one-time coordinate, and their identity resolves locally: at the service desk, at login, and at a password reset.

It sits in the Conversational AI pillar of our Avatier Identity Anywhere 2027™ series. The Conversational Identity hub covers the wider shift of identity work into chat, voice, and AI assistants. This piece covers the authentication floor underneath that shift.

What an Identity Continuity Layer is, and what it isn't

An Identity Continuity Layer is defined by a property rather than a factor: it's the part of the stack whose job is to keep authentication available when the other parts can't run. Put plainly, an Identity Continuity Layer is a deviceless authentication layer that runs alongside an organization's existing MFA and takes over the moments device-dependent MFA can't serve. It doesn't depend on a phone, an app, a hardware token, or a network connection at the point of use.

Three distinctions keep the definition clean.

It's a layer, not a replacement. The continuity layer doesn't ask anyone to rip out Microsoft Authenticator, Okta, Duo, passkeys, or FIDO2 keys. Those stay the primary methods wherever they work. The continuity layer covers the moments, and the people, they don't reach.

It's deviceless by definition. A backup authenticator app on a second phone isn't a continuity layer. It moves the single point of failure instead of removing it. SMS to a backup number isn't one either. The test is simple: if the fallback needs a working device, a charged battery, or a signal, it fails in the same conditions as the primary factor.

It isn't a chat or voice feature. Conversational channels make the layer more important, but the layer itself is authentication infrastructure. It answers one question: is this the person they claim to be, when their usual device can't vouch for them?

The category needs a name because the gap has been handled informally for years, through MFA exceptions, temporary bypass codes, and help-desk resets granted on the strength of a convincing voice. A continuity layer replaces those with a governed control.

Where device-dependent MFA breaks

Every mainstream MFA method assumes a trusted device is available at authentication time. SMS and voice codes, TOTP apps, push authenticators, FIDO2 security keys, hardware tokens, biometrics, passkeys, and smartcards all share that assumption. None of them are deviceless. That's the design premise of the whole category, and it holds most of the time. It fails in predictable situations.

Failure mode	What actually happens	Why device MFA can't help
Lost or broken phone	The authenticator, the passkey, and the SMS number are all on a device that's gone or cracked	The factor is the device. No device, no factor.
Dead battery	The phone is present but off, often at the end of a long shift	Push, TOTP, and SMS all need power
No signal	Basements, plant floors, clinical areas, remote sites, aircraft cabins	SMS and push need a network, and many flows need one to enroll or sync
Shared or frontline devices	A kiosk, a nursing-station workstation, a virtual desktop, a scanner passed between workers	The device isn't bound to one person, so it can't prove which person is using it
Travel	A replacement phone, a roaming SIM, a new number, a device left at home	Number-bound and device-bound factors break when the device or number changes
BYOD refusal	A worker declines to install a work app on a personal phone, or doesn't own a smartphone	There's no approved device to hold the factor

The first four come straight from the working conditions the Identity Challenge Card was built for: phones that are dead, out of signal, or in a locker, and workstations that had a different worker an hour ago.

In frontline-heavy industries these aren't edge cases. Retail floors, hospitals, plants, logistics hubs, and field service are organized around people who can't or won't use a personal phone on the job. Each failure produces a person who legitimately needs to get in and has no approved way to prove who they are.

The usual organizational response is the MFA exception: a documented list of workers, roles, or sites where the MFA policy doesn't apply. Exceptions keep the business running. They're also the part of the environment an attacker maps first.

Five different device failures, one destination. Each one sends a worker to a help desk that now has to verify them without their usual factor.

How a device failure becomes a help-desk reset and a vishing opening

When the device fails, the worker doesn't stop needing access. They call someone. That handoff is where a device problem turns into an identity problem.

A worker's phone dies mid-shift, or they've replaced it and the authenticator didn't come along. They call the service desk, and an agent now has to decide whether to trust a voice on the phone. The usual tools for that decision are weak.

• Texting a code to the caller's phone assumes the phone is theirs. If the reason for the call is a lost or compromised phone, that assumption is backwards. The code may land on a device an attacker already controls.
• Knowledge-based questions such as employee ID, manager name, or hire date are a list of facts an attacker can research.
• Calling back the number on file fails when the number on file belongs to the phone that's gone.
• Manager vouching moves the decision to someone who is also just recognizing a voice and adds delay.

This is the recovery-channel problem our Beyond Foundational MFA piece covers in depth. In most enterprises the front door got strong, and the way back in didn't. The OTP failure scenarios reference walks through the same pattern from the one-time-password side, where email recovery, security questions, backup codes, and verbal verification each end up weaker than the factor they stand in for.

It's also where vishing lives. A voice-phishing attacker doesn't need to defeat MFA cryptography. They need to sound like a stressed employee with a dead phone, at the right desk, at the right hour. The more often legitimate workers call in with device problems, the more normal that story sounds, and the harder it is for an agent to tell the real call from the fake one. The MFA bypass techniques guide covers how help-desk social engineering fits next to SIM swap and adversary-in-the-middle attacks.

So device failure carries two costs: operational (tickets, resets, time off the floor) and security (every reset granted on a weak check is a potential account takeover). A continuity layer addresses both with a check that doesn't depend on the device that just failed.

Without a continuity layer, recovery depends on how convincing a caller sounds. With one, the worker proves identity with something they hold.

How the Identity Challenge Card implements the layer

The Identity Challenge Card is Avatier's implementation of the Identity Continuity Layer. This section reflects only how Avatier describes the product.

The card. It's a printed grid of word pairs, organized by coordinates such as A1 or C2, with a top word and a bottom word at each coordinate. No phone number, biometric, or personal data touches the card, and its contents are opaque without the user's PIN.

Three factors, resolved locally. Avatier describes the card as resolving three independent factors, all locally, all without a device, and all in under 10 seconds.

1. Challenge Card Factor. The system asks for a specific coordinate, and the user reads the answer directly off the card. There's no network call and no device.
2. Private Knowledge Factor. A short PIN that only the user knows, bound to the card through policy and verified in memory.
3. Identity Anchor Factor. The user's directory identity, such as an Employee ID, a badge, or a SCIM-provisioned principal. It ties the challenge to a specific human, with a full audit trail.

All three are required. The word and the PIN both have to be correct.

One-time values. Each coordinate value is used once. After a value has been read and accepted, it's spent, so a value overheard on a call or glimpsed over a shoulder doesn't work a second time. There are no push notifications, so push fatigue has no surface, and there's no TOTP shared secret to steal.

Three moments, one card. Avatier positions the same card across the three moments a credential gets proven, replaced, or recovered.

• At the service desk. Someone calls asking for their access back. The agent names a coordinate, the caller reads the answer off their printed card, and that value is spent. The desk resolves the answer against the grid locally, with no identity-provider call and no network dependency. It's a live identity check that doesn't rely on a device the attacker may already control.
• At login, with or without a password. Some sites sign in without a password, and some keep the password and add a factor. The card is the factor either way. On shared workstations and virtual desktops, the factor isn't provisioned into the machine; it's in the worker's pocket. Where the password stays, the card answers the MFA challenge after the password is accepted.
• At a password reset. A locked-out worker resolves it themselves. A coordinate appears, the worker reads the word and adds the PIN, the employee ID is verified automatically, and then the password changes. There's no call, no ticket, and no manager override, and it still works when the phone is dead, out of signal, or in a locker.

Governed lifecycle. Cards are issued through the organization's existing IGA workflow. Issuance, expiration, re-enrollment, and revocation are logged and policy-enforced. Admins set expiry windows, and users get automated reminders. Re-issuance is identity-verified, which closes the social-engineering path around replacing a card, and duties are separated among issuer, approver, and auditor. A lost card is revoked in seconds and replaced the same day, and re-enrollment needs no device pairing.

Deployment. Avatier describes deployment in under an hour, with no MDM, no app, and no hardware. Workers can self-enroll, or an organization can auto-enroll everyone at once.

Apple Wallet. An Identity Challenge Card for Apple Wallet is also available, as a fast backup identity for when standard MFA fails. Avatier positions it alongside the printed card, not instead of it. The printed card is what keeps the layer deviceless.

34 languages, printed card included. A fallback only closes the gap if every worker can read it. Avatier's universal user experience covers 34 languages across every channel, including the printed card. The Identity Challenge Card ships in 34 languages, including right-to-left scripts such as Arabic and Urdu and the CJK scripts for Chinese, Japanese, and Korean, with the same three-factor flow in each. That matters more for a card than for a push prompt with two buttons. The worker has to find a coordinate and read a word, often under time pressure and sometimes aloud to an agent, so localizing the card itself is what makes the layer usable on a multilingual plant floor or hospital ward.

How it fits alongside the MFA you already run

A continuity layer isn't a competing MFA product. It's the one method in the stack that doesn't share the others' failure conditions.

In Avatier's framing, the card sits alongside the MFA you already run, and policy routes each worker to the right method, even where device MFA can't reach. On the Avatier Identity Anywhere platform, deviceless authentication appears in the MFA and adaptive-authentication support layer next to OTP, TOTP, FIDO2, hardware security keys, and biometrics. That same "Any MFA" layer lists Microsoft and Google authenticators, Okta MFA, Duo Security, PingID, CyberArk, YubiKey, passkeys, RSA SecurID, and Fortinet. Avatier runs alongside identity platforms such as Microsoft Entra ID, Active Directory, Okta, and Ping rather than replacing them.

In practice, a continuity layer tends to land in one of three policy roles.

1. Primary factor for workers without an approved device. Shared-workstation, virtual-desktop, and frontline roles, where the organization writes MFA exceptions today, use the card as their factor, with or without a password.
2. Fallback when the primary factor fails. A desk worker who normally uses a passkey or a push app uses the card when the phone is lost, dead, or offline, instead of calling for a reset.
3. Verification at the recovery moment. The service desk and self-service password reset use the card to confirm identity before any credential changes, so recovery is no longer the weakest path in.

The phishing-resistant MFA reference makes the case for FIDO2 and passkeys at the front door wherever managed devices exist. The adaptive authentication piece covers the risk policies that decide which method a given sign-in gets. The continuity layer is what those policies can route to when the preferred method isn't available, which gives them a governed option in place of an exception.

Device MFA stays primary wherever it works. The continuity layer sits underneath with no shared failure conditions, so authentication has somewhere to go.

Why continuity matters more as identity moves into conversation and voice

Identity work is leaving the portal. Identity Anywhere 2027 delivers identity experiences across web, mobile, Microsoft Teams, Outlook, chat, voice, phone, APIs, and MCP-compatible AI assistants. A worker who once opened a self-service page now asks for access in a Teams chat, calls a phone line to unlock an account, or has an assistant in Claude or Microsoft Copilot start the request for them. The Conversational Identity hub maps that shift, and our Teams access-request piece walks through one of its most common forms.

That shift raises the stakes on authentication in three ways.

The channel carries less proof. A portal session sits behind a browser, an SSO session, and often a managed device. A phone call carries a voice. When a request comes in by voice, the system has to establish who's speaking, and a voice is exactly what vishing imitates. A challenge that doesn't depend on recognizing the voice, and doesn't send a code to a device the caller claims to have, holds up in that channel. The card's service-desk flow was built for exactly this: the agent reads a coordinate down the line, and the caller reads the word back off a printed card.

The assistant is the interface, never the authority. In Avatier's MCP design, AI assistants don't get unrestricted access. Every request has to invoke an approved Avatier capability and stays subject to authentication, authorization, delegated authority, policy enforcement, and audit controls. That puts more weight on authentication, not less. If a person can't authenticate because their phone is dead, a conversational front end just moves the dead end to a friendlier screen. The Identity for AI Agents piece covers where human step-up fits inside agent workflows.

Resets and unlocks are the requests that arrive after a device fails. Password resets, account unlocks, and identity verification are among the Secure Outcomes Avatier's platform is built around. A conversational channel that can process a reset quickly, but can't verify the requester when their phone is gone, has rebuilt the help-desk problem in software.

The continuity layer isn't a conversational feature. It's what makes conversational identity safe to offer to people whose devices aren't reliable.

What Avatier ships toward this pattern

This section sticks to what Avatier has published.

• The Identity Challenge Card™ is the product that defines the Identity Continuity Layer category. It's a printed, three-factor, deviceless credential used at the service desk, at login, and at password reset, deployable in under an hour with no MDM, app, or hardware.
• Avatier Identity Anywhere 2027™ is Avatier's AI-native identity platform built on the Model Context Protocol. It treats authentication, password resets, account unlocks, and identity verification as Secure Outcomes: completed, verified, policy-compliant activities. Each Secure Outcome records the identity involved, the initiating agent or experience, the authorization context, the policy applied, the action taken, and the final result.
• Pay Per Identity Action™ is the commercial model behind the platform. Customers pay only for completed, verified, policy-compliant identity outcomes. Getting started is free, deployment services are included, and a 45-day money-back guarantee applies under the Avatier Secure Outcome Guarantee™. Full commercial terms go to qualified organizations in the invitation-only preview. The Pay Per Identity Action hub explains the model.
• It runs alongside existing investments. Avatier works alongside Microsoft Entra ID, Active Directory, Okta, and Ping, and alongside SailPoint, Saviynt, ServiceNow, and Moveworks.
• Security posture. Avatier is SOC 2 Type II audited with zero exceptions noted, ISO/IEC 27001:2022 certified, PCI DSS v4.0.1 compliant, and CSA STAR Level 1, and it's NIST 800-53 Rev. 5 aligned and a CISA Secure-by-Design Pledge signatory. Details are published at the Avatier Trust Center.
• Track record. Avatier was founded in 1997, is based in Pleasanton, California, and has sold over 15 million licenses. A healthcare organization with more than 100,000 identities is running or piloting the Identity Anywhere platform.

What an Identity Continuity Layer doesn't solve

A continuity layer closes one specific gap. Being clear about its edges keeps it from being oversold.

It doesn't replace phishing-resistant MFA where devices work. For workers with managed devices, FIDO2 keys and passkeys remain the strongest front-door option. The continuity layer covers the times and places they can't run.

It doesn't make workers immune to coaching. One-time values mean a coordinate read aloud can't be reused, and the PIN means a found card isn't enough on its own. But the control assumes the worker reads values only to the verifier that asked for them: the login screen, the reset page, or the agent who started the check. Awareness training still has to cover the reverse case, where someone calls the worker and asks them to read from their card.

It doesn't govern what happens after sign-in. Authentication establishes who someone is. It doesn't limit what they can reach, detect a stolen session token, or catch an over-privileged account. Those jobs belong to access governance, session controls, and identity threat detection.

It has physical logistics. Paper has to be printed, handed out, replaced when lost, and reissued when it expires. IGA-driven issuance, expiry windows, automated reminders, and same-day replacement make that manageable, but it's still an operational process with an owner.

It doesn't settle your assurance mapping for you. Regulators and frameworks set their own requirements for authenticators, and each organization has to map any method, this one included, against the frameworks it answers to. Avatier helps support evidence needs for frameworks such as NIST, SOX, HIPAA, and GDPR. It doesn't make that determination on your behalf.

Inside those limits, the argument is simple. Device-dependent MFA is the right default, and it will keep failing in the same predictable places. Without a continuity layer, what happens next is an exception list and a help desk trusting voices. With one, the worker proves who they are with something they hold, and the recovery path stops being the easiest way in.