Why strong workforce authentication isn't the same as strong identity — and attackers know it

You’ve done the hard work. You’ve implemented strong authentication methods, like passkeys, push notifications, and FastPass. Your MFA posture is, by most measures, pretty darn solid. So why are identity-based attacks still succeeding against organizations that look exactly like yours?

The reality is, attackers stopped trying to break your authenticator. They're working around it by finding weakness in your identity verification flows, and AI is making that easier. Deepfake voices that fool helpdesk agents. AI-generated synthetic identities that pass document review at onboarding. Social engineering scripts refined and personalized at scale. The moments your authenticator was never designed to protect are now being targeted with more sophisticated tools than ever.

The shift to strong, phishing-resistant authenticators marks one phase of identity evolution, but sophisticated attacks are now driving the need for the next: rigorous identity verification.

A question we hear often is, “If a verifiable digital credential can prove who I am, why can't I just use it to log in?” The short answer: proving who you are and proving you're back are two different problems. 

The good news is that verifiable digital credentials (VDCs) offer a solution to this problem. Let’s dive into better understanding what method is best for both authentication and verification scenarios to shed light on potentially dangerous blind spots.

The distinction that matters most

Most identity systems are designed to answer the question "Is this the same person or device that was here before?" That's what your authenticator does. It confirms continuity. They're fast, silent, and built for the reality that your employees or customers interact with your systems dozens of times a day.

But there's a second question that comes up less frequently and carries far more risk: "Who is this person, actually?"

This question surfaces at specific moments, like when someone joins your organization for the first time, when they call the helpdesk after losing their phone (and their authenticators), or when they're a contractor who has never been in your system before. Today, most organizations answer it with authentication factors misused as identity checks: security questions, video call verification, or SMS codes. They confirm someone has access to a phone number or knows past answers — not who they actually are.

They work until an attacker decides to target them, which is exactly what happened in a highly publicized 2023 breach in the hospitality industry, where the entry point was a social engineering call to the helpdesk, not a broken authenticator.

VDCs are purpose-built for proving who you are. They cryptographically verify real-world identity attributes, like a government-issued ID, employment status, and a professional license, without relying on human visual inspection or easily spoofed factors.

The three dimensions of identity trust

It helps to think about identity trust as having three separate dimensions, each doing a different job.

Identity Assurance — "Who is this person?"

Verifying that a human matches real-world identity attributes, like a government ID, employment status, or a professional license. This is a job for VDCs. It matters most when you haven't established a relationship yet, or when that relationship has been disrupted.

Authenticator Assurance — "Have I seen this person before?"

Confirming that a known entity is returning to an established session. This is the job of passkeys and FastPass — your daily login tools. They're optimized for high frequency and low friction.

Device Assurance — "Is this device healthy?"

Confirming the device meets security requirements: disk encryption, OS patches, firewall status, jailbreak detection. FastPass carries device health signals, but they're evaluated separately from the authentication event (backchannel signals, not embedded in the auth itself). Passkeys and VDCs do not include device assurance.

No single tool covers all three dimensions. The goal is to deploy each where it's strongest, and to recognize that gaps in any one dimension are exploitable, regardless of how strong the others are.

See how these dimensions play out in practice, starting with what your existing authenticator covers, where its boundaries are, and then where VDCs fill the gap.

FastPass in workforce contexts: The daily hero (and it's one structural limit)

Let's be direct: If you require device context, FastPass is one of the most secure and seamless daily login experiences. It's phishing-resistant, operates silently with almost zero user interaction, and bundles device posture signals directly into the authentication event. For the returning-user problem, it's the right answer.

But FastPass proves two things and only two things: the device is trusted, and the authentication method set up on that device is valid.

It does not verify that the right human was enrolled in the first place. This is not a flaw. It's a definitional boundary. FastPass answers dimensions two and three with precision. Dimension one, identity assurance, has to be answered before FastPass exists for a given user.

The day zero problem

An adversary doesn't need to defeat phishing-resistant MFA if they can fraudulently enroll before it's issued. If they social-engineer your helpdesk into provisioning credentials to the wrong person, or intercept a temp-code onboarding flow and enroll their own device, then FastPass will faithfully authenticate that bad actor on every subsequent login.

Put another way, if the right checks weren’t in place to verify a user’s identity on day one, FastPass may be authenticating the wrong person forever.

This is the enrollment integrity problem. It's why sophisticated attackers have shifted focus away from authentication itself and toward the moments surrounding it.

The three workforce identity gaps VDCs fill

Gap 1: Onboarding — before the authenticator exists

You can’t use an authenticator to verify identity before that authenticator has been issued. Yet this is precisely the moment when identity needs the most rigorous verification.

Now add AI into the mix: AI-generated synthetic identities have made document fraud at onboarding significantly more sophisticated. Traditional document review, whether by a human or a basic automated scan, was not designed to detect deepfakes. 

VDCs carry cryptographic signatures from issuing authorities. There is no AI-generated equivalent of a valid cryptographic signature from a state DMV or a trusted employer. So, with a VDC, you can cryptographically verify the person's real-world identity before their account exists, then bootstrap their first passkey or FastPass enrollment from that verified identity. The first authenticator enrollment is trustworthy because the identity behind it has been independently confirmed. By adding a VDC check at the start, Fastpass can now faithfully authenticate the right person forever.

Gap 2: Helpdesk and account recovery — when the authenticator is gone

When a user loses their phone, they lose their authenticator, and your organization has to fall back to something. What that something is defines your actual security posture, because attackers know this fallback path better than your tier-1 support agents do.

SMS codes, security questions, and video call identity checks are soft targets. AI-generated voice cloning and deepfakes have made helpdesk recovery one of the most reliably exploitable surfaces in enterprise identity. The assumption that a human agent can verify identity by recognizing a voice, seeing a face on video, or reviewing a document is no longer reliable.

A government-issued VDC, such as a mobile driver's license or a digital passport, provides a verification path completely independent of the lost corporate device. The user presents their credential from their personal digital wallet. Cryptographic verification confirms who they are. A cryptographic signature provides defenses against social engineering.

One important nuance worth noting: this independent recovery advantage applies specifically to government-issued VDCs. Government-issued credentials are the right tool for account recovery precisely because they exist outside your organization's trust chain.

Gap 3: The extended workforce — where FastPass can't reach

Frontline workers, contractors, seasonal employees, and external partners represent a significant portion of your access footprint, and many of them can’t install a managed corporate application. Many organizations face regulatory or internal policy restrictions regarding employer software on personal devices. BYOD policies create ambiguity. Shared devices make per-user enrollment impractical.

This population typically ends up with the weakest security — shared passwords, no MFA, or exclusion from your managed identity program entirely. None of these outcomes is acceptable.

VDCs can live in native mobile wallets like Apple Wallet®, Google Wallet™, and Samsung Wallet, so there are no corporate apps to install, and no IT provisioning is required. A contractor presents a phishing-resistant, cryptographically signed identity credential from their personal phone at onboarding, for step-up verification, or for periodic re-verification. You get high-assurance identity coverage for a population that was previously outside your security perimeter, without touching MDM or managed endpoints.

The best practice: Verify first, then authenticate

The strongest identity strategy isn't VDCs or strong authenticators. It's both, each deployed where they're strongest. In practice, that looks like this:

1. Verify identity with a VDC at onboarding, helpdesk recovery, or any moment where you need to establish or re-establish trust in who someone actually is.
2. Bootstrap a strong authenticator, passkey, or FastPass from that verified identity, so the daily login credential is rooted in real-world proof, not a trust-on-first-use assumption.
3. Use the authenticator for daily access. Fast, silent, and no identity attributes are shared unnecessarily.
4. Bring VDCs back when the stakes rise again, account recovery, sensitive transactions, or any moment where security key possession alone isn't sufficient.

For workforce environments: VDCs handle onboarding, helpdesk, and extended workforce coverage. FastPass or passkeys handle daily login, unchanged and uninterrupted, while FastPass adds device assurance signals that neither VDCs nor passkeys carry.

For consumer environments: VDCs handle identity verification at signup, replacing manual document review at account recovery and high-value transactions. Passkeys handle returning sessions. The experience improves on both sides: faster onboarding, lower friction daily access.

A clear line on daily login

This point deserves explicit emphasis: VDCs are not a daily login factor.

Every VDC presentation involves a consent flow and shares identity attributes with the relying party. That's the right design for a high-stakes moment, but it’s disproportionate friction for checking email or accessing a SaaS tool repeatedly throughout a work day.

Instead, the job of daily login belongs to FastPass and passkeys. VDCs and authentication credentials share some technical traits — phishing resistance, cryptographic signatures, and user interaction — and that overlap leads some teams to treat them as interchangeable. They are not. Deploying VDCs in daily login flows adds friction without adding security at that layer. Deploying authenticators at onboarding and recovery leaves identity verification gaps where attackers concentrate.

The clearest way to hold the distinction: VDCs prove who you are. Authentication credentials prove you're back. You need both at different moments.

Coverage by deployment model

How you combine these tools depends on your workforce model. Here's how the three dimensions map to common deployment patterns:

Where to start

If you're evaluating where VDCs fit, begin by mapping your critical identity moments. The points in your user lifecycle where you're currently relying on weak signals to answer "who is this person?"

• How do you verify a new hire before issuing their first credential?
• What happens when someone calls your helpdesk after losing their device?
• How do contractors or frontline workers prove their identity without a corporate app?
• What step-up verification method do you use for your most sensitive transactions?

These are your highest-leverage deployment points. Low frequency, but disproportionate security impact — and they're also where breaches start.

Your front door might already be well-protected. The question is whether you verified who was standing there before you handed them the key.

One option worth considering: employment credentials. You don't have to rely solely on government-issued VDCs. With Okta, you can soon issue cryptographically signed employment credentials directly.¹ These are custom employment VDCs that your workforce can carry in a digital wallet. This gives you the same phishing-resistant verification benefits as government credentials, but tailored to your specific workforce needs and integrated directly into your identity infrastructure. Combined with government-issued VDCs for account recovery and contractor access, you get layered, high-assurance identity coverage across your entire extended workforce.

If you want to evaluate your organization's coverage across all three dimensions of identity trust, the identity assurance gap is the right place to start. It’s the one your current posture is least likely to address. Explore Okta Digital ID Verification Beta to see how VDCs fit into your stack.

¹ Any products, features, functionalities, certifications, authorizations or attestations referenced but not not currently available or have not yet been obtained or are not currently maintained may not be delivered or obtained on time or at all. Product roadmaps do not represent a commitment, obligation or promise to deliver any product, feature, functionality, certification or attestation and you should not rely on them to make purchase decisions. Okta may decline to make any product feature, functionality, or decline to pursue or maintain any certification, authorization or attestation in its sole discretion.

These materials are intended for general informational purposes only and are not intended to be legal, privacy, security, compliance, or business advice. © Okta and its affiliates 2026.

Apple Wallet® is a registered trademark of Apple Inc., registered in the U.S. and other countries. Google Wallet™ is a trademark of Google LLC. Samsung Wallet is a trademark of Samsung Electronics Co., Ltd.