Passkeys and FIDO2 in the enterprise: a migration plan

Why move away from passwords and what passkeys bring

Passwords fail not because employees are “bad,” but because passwords are simply inconvenient. They must be created, remembered, changed by rules, and entered on different devices. That leads to habits that make a company vulnerable.

Typical problems: an employee enters a password on a phishing page; the same password is reused across systems; a password appears in a breach from a third-party service; weak passwords and written notes appear (especially among staff who frequently change workplaces or work in the field). Support load also grows: resets, lockouts, identity checks.

Passkeys, in simple terms, are sign-ins without passwords. Instead of a “secret word,” a cryptographic key tied to a device is used and confirmed by biometric verification or a PIN. A key difference from passwords and one-time codes (OTPs) is that a passkey cannot be phished on a fake site. It only works with the genuine service and does not reveal a secret during entry.

For employees it usually feels like unlocking a phone or workstation: touch your finger or enter a PIN and you’re in. For IT and support the benefit is also clear: fewer password reset requests, but more focus on key issuance rules, device management and recovery scenarios.

Start moving to passwordless authentication once you have basic discipline in tracking users and devices and the business is tired of phishing and constant resets. In organizations with hundreds of seats (offices, classrooms, reception desks) passkeys often give quick practical results: people sign in successfully more often and stumble over passwords less.

It’s too early to start if you don’t have a clear process for lost devices or if critical applications aren’t ready for modern sign-in methods. In that case, introduce passkeys and FIDO2 with a small pilot and fix gaps in parallel. Otherwise the first incidents will quickly erode user trust.

Passkeys and FIDO2: terms you must not mix up

In corporate discussions Passkeys and FIDO2 are often conflated. That creates wrong expectations: some think “FIDO2 is one specific key,” others assume passkeys only work on smartphones.

FIDO2 is a set of standards that describe how passwordless sign-in works and how an application and an authenticator communicate. Simplified:

• WebAuthn — the application-side (mostly web) part that defines the sign-in request.
• CTAP2 — the part that defines communication with the authenticator (hardware key, phone, etc.).
• FIDO2 — the umbrella combining WebAuthn and CTAP2.

A passkey is a user-facing credential based on FIDO. Technically it’s a key pair: the private key stays in the authenticator, the public key is held by the service. The user confirms sign-in with biometrics or PIN, but the secret is never typed or transmitted.

An authenticator can be different things — and that matters for security policy:

• a hardware security key (USB, NFC);
• a phone as a key (confirmation on the device);
• built-in biometric and a secure module in a laptop;
• a smart card or corporate token (if your environment supports it).

In practice, these are used for web sign-in and portals, VPN and remote desktop access, unlocking workstations, and admin access to critical systems. For administrators, stricter options are chosen: separate hardware keys and a ban on syncing to personal devices.

The anti-phishing protection relies most on binding to device and resource. Credentials are created for a specific service, and the authenticator checks the domain (or application identifier). So even if an employee opens a fake page, the passkey won’t match it and the secret can’t be phished like a password or OTP.

Quick readiness check: what to verify before a pilot

Before a pilot, map where passwords are entered today and who manages access. Usually 1–2 meetings with IT and security are enough to spot bottlenecks and save weeks.

Start with an inventory of entry points. Besides mail and corporate portals you’ll often find VPN, VDI, CRM/ERP, admin consoles, service accounts and contractor access. For each system record: how sign-in is done, whether MFA exists, and whether FIDO2 can be added without rewriting the application.

Next, check where the “access control center” lives: a single IdP/SSO, AD domain, cloud directory, or a hybrid. For a pilot it’s critical to know where you’ll apply policies, collect logs and quickly roll back changes if part of the user base gets stuck.

Devices are a separate topic. Passkeys and FIDO2 depend on real hardware: which OSes employees use, whether there are mobile devices, kiosks and shared PCs, and how people work on the road. In a government office with shared reception computers, binding a key to a personal profile is harder than in an office with individual laptops.

To keep things focused, gather a minimal readiness dataset:

• list of entry points and their priority (what must not break);
• the access control point and current MFA policies;
• device inventory and scenarios (office, remote, shared-PC);
• InfoSec and regulatory requirements: logs, retention, audit trails;
• support capabilities: who helps users and when.

One more filter — investigation requirements. Security teams usually need clear events: who signed in, how they confirmed it, from where, and how access was restored. If you don’t define this before the pilot, projects often stall on approvals rather than technology.

Step-by-step rollout: from pilot to scale

Treat the move to passkeys as a phased project, not a one-time “password swap.” The main risk in enterprises is organizational: who’s in the pilot, what to do if a device is lost, and when the password stops being the fallback.

1) Pilot: short, measurable, with real users

Set pilot goals: usually fewer phishing incidents, easier sign-ins, and fewer support tickets for password resets. Choose groups where impact will be visible and policies are followed.

Good pilot candidates: IT and helpdesk (they’ll exercise recovery flows), finance and accounting (high-value accounts), managers (common phishing targets), front-office and operators (many daily sign-ins), and remote staff (work outside the perimeter).

Agree success criteria beforehand, otherwise the pilot becomes “we tried it and forgot.” Typical metrics: share of passwordless sign-ins in pilot systems, drop in reset/block tickets, mean time to recover access after device loss, and number of phishing or suspicious sign-in incidents.

2) Communications and support: prevent panic

Prepare short instructions: what changes, how to sign in, where to get help, and what to do if a phone or key is lost. Also agree who and how verifies identity for recovery so it’s not a “ask the boss to write in chat” process.

Example: the pilot runs on IT and finance, and on day one someone in finance changes phones. If the recovery process is documented and support knows the steps, it’s a 15-minute outage instead of half a day without access.

3) Scale in waves and set password cut-off dates

After the pilot, plan expansion in waves by department and by application. For each wave set a date to enable passkeys and a separate date when passwords stop being the primary sign-in (or are disabled where possible). Start with systems that already support FIDO2 and move to harder ones later.

This rhythm reduces chaos: users know what’s changing now, IT can adjust policies and training based on real issues rather than assumptions.

Application compatibility: handling legacy without chaos

The main risk is not the keys but the heterogeneous app landscape. To avoid endless exceptions, keep a simple compatibility matrix and update it during the pilot.

List entry points: web portals, VPN, VDI, mail, ERP/CRM, admin consoles, service accounts, contractor access. For each record whether it supports WebAuthn/FIDO2 natively, has SSO, which protocols are used (SAML, OIDC, RADIUS), and whether it can be upgraded without business interruption.

Keep the matrix tidy by:

• classifying apps into 3 groups: ready now, ready via SSO, not ready;
• marking browser-based sign-in (usually easier) versus client apps (often harder);
• flagging admin and privileged access;
• assigning an app owner and an update window;
• deciding what is a temporary 3–6 month workaround and what must be fixed permanently.

Common problem areas repeat: old web apps may not support modern sign-in, or break due to outdated ciphers or embedded login forms. Thick clients often only accept username/password and need lengthy approval cycles for updates. RDP/SSH is a special case: it’s not browser passkeys but integration with corporate accounts, certificates or an access gateway.

Typical mixed approaches help:

• sign-in via SSO (the app stays as-is, the IdP changes the sign-in policy);
• gateway/proxy for legacy apps (strong checks at the gateway, then access to the old app);
• upgrade if the product is supported and maintained;
• replace if support has ended and risk grows;
• a dedicated managed path for RDP/SSH (bastion host, VDI or other controlled entry).

Don’t break external users. Contractors, auditors and partners often can’t adopt your standard immediately. Use separate policies: require FIDO2 for employees and admins, while external users get restricted SSO access with stricter conditions (time limits, IP, device restrictions) and a dedicated access process.

Practical example: part of the organisation uses modern web systems, another part uses an old client. Launch the pilot on the modern group via SSO and FIDO2, and implement a temporary gateway for legacy apps with a scheduled upgrade plan. Progress is fast and calm.

Key requirements and role-based policy

Decide in advance which authenticators are allowed and who gets which. A mixed approach often works best: platform authenticators (built into laptops or phones) offer convenience, while hardware keys provide predictability and a fallback.

Platform passkeys suit most staff: fast sign-in, fewer forgotten secrets, easier support. Hardware keys are appropriate where risk is higher or devices change frequently (shift workers, shared access, travel, or secure segments).

Basic key requirements

Keep rules simple but mandatory:

• hardware keys must have a local PIN and lock after several wrong attempts;
• no “copyable” workflows: do not export secrets to files or uncontrolled third-party stores;
• standardised procurement (models and compatibility) so support and training are predictable;
• clear trust criteria: certification and supply provenance, especially in public sector and critical systems;
• define where a key is permitted: workstations, laptops, terminals, remote access.

How many keys per person depends on role. Most need one primary method (e.g., a passkey on a corporate laptop) and one backup (hardware key or second registered device). The backup should be stored separately—not in the same case as the laptop or “in the shared drawer.” Practical approaches: inventory and keep the backup in a sealed envelope or a departmental safe.

Policy for admins and privileged roles

Admins should use separate keys and stricter controls. Risk-reducing measures:

• two hardware keys (primary and backup), both PIN-protected;
• ban using a personal phone as the sole factor;
• separate keys for admin tasks and normal office work;
• register new passkeys only via an approved process.

Policy needs device manageability. Use MDM/endpoint controls to forbid registration on unmanaged devices, enforce screen lock and updates, and track issued keys. In projects with standardised endpoints and transparent supply chains, a single partner handling both infrastructure and device supply often reduces variance in settings.

Example: accounting signs in with passkeys on corporate laptops; domain admins have two hardware keys, one stored in the shift manager’s safe. When staff leave, keys are returned and accounts closed the same day so access doesn’t remain on old devices.

Access recovery: rules that save the project

Passwordless projects more often fail at recovery than at sign-in. If someone loses a key, breaks a phone, changes devices or travels without a backup, they’ll stop work or try to bypass rules. Define recovery scenarios before the pilot and include them in policy.

Two principles suffice: identity must be verified reliably, and access returned quickly. Recovery should not be a five-approval “quest,” but it shouldn’t be granted via a chat message either.

Basic scenarios and what to prepare

Plan for typical cases:

• lost key: block it, issue a new one, check active sessions;
• broken phone: move the passkey to a new device or sign in with a backup key;
• device change: add a new key only after identity confirmation;
• travel: provide temporary access for a limited time without elevating privileges;
• suspected compromise: force logout of sessions and rebind keys.

Use 2–3 verifiable signals for identity checks: corporate badge plus face check, phone call to an HR number, or manager confirmation via an approved channel. Don’t rely on a single channel as the only recovery point.

Issue backups ahead of time: a second key stored separately, a clear procedure for temporary access, and who approves it. Temporary access must expire automatically and never grant admin rights.

Termination, role transfer and break-glass

On termination or role change act fast: revoke keys, close active sessions, review bound devices and run a short audit of recent sign-ins. Role transfers (e.g., shift coverage in a data centre) must be formalised rather than “hand the key to someone.”

Break-glass accounts are only for emergencies. Keep them minimal and tightly controlled: enable only for incidents, log the reason, notify security and force credential rotation after use.

Example: an engineer loses a key while travelling. Instead of a password, they get an 8-hour temporary access limited to the required system. On return they confirm their identity and register a new key. Work continues and policy stays intact.

Common mistakes when moving to passkeys

Failures are rarely technical; they’re about rules and support. Even if devices and your IdP already support passkeys and FIDO2, users will find workarounds if the process is inconvenient or unclear.

The most common mistake is making passkeys mandatory for everyone overnight. That creates shadow IT: employees ask colleagues to sign in for them, store one-time codes in notes, or demand the old way back. Safer: start small and expand only after you understand failure modes.

Five frequent failures:

• forcing everyone over without a pilot and early exceptions;
• ignoring shared PCs and shift-based work (reception, contact centre, clinics, classrooms) where phone-based sign-in isn’t feasible;
• keeping the password as the primary method while adding passkeys “for convenience” — phishing and reuse remain;
• an ill-prepared helpdesk: no scripts, statuses, or safe recovery tools — users will bypass rules;
• applying the same rules to employees, contractors and admins despite different risk profiles.

About shared PCs: decide in advance how people will sign in. Options include hardware keys, short-time sessions with timeouts, or dedicated accounts for the workstation. If you don’t decide, these points will force a return to passwords.

Admins usually need stricter controls: two independent keys, no weak-factor recovery, and a pre-registered backup method. That’s often cheaper than downtime caused by a locked privileged account.

Also anticipate a support spike in the first 2–3 weeks. If helpdesk is ready, users adapt faster and trust in the project remains high.

Short checklist before launch

Before enabling passwordless sign-in for everyone, prepare a minimal set of solutions and rules to avoid schedule slips over “one legacy app” or an unclear recovery process.

Five questions that need clear answers:

• Who’s in the pilot and why. 1–2 pilot groups chosen (e.g., IT and helpdesk, then finance or contact centre agents). Agreed metrics: share of successful sign-ins, helpdesk tickets, recovery time, and percent of apps without passwords.
• Which apps are ready and which are not. A list of daily systems: mail, ERP/CRM, portals, VDI, VPN, admin consoles. For hard apps choose a path: upgrade, replace, SSO entry, or a temporary exception with an end date.
• Which keys are allowed and how many backups. Approved authenticator types (hardware, platform, mobile) and rules on numbers. Critical roles require at least one primary and one spare. Define policies for contractors, shift workers and field staff.
• How to recover access without chaos. Documented procedures for “lost device/key,” “changed phone,” and “suspected compromise.” Helpdesk trained: acceptable identity checks, approvers, expected times, and events to log.
• What to log and how to respond. Configure logs for sign-ins, failures, key registrations and recovery actions. Assign responsibility: who notices anomalies (mass failures, new key registrations at night, attempts across accounts) and what steps are taken on an incident.

Practical test: pick 10 pilot users and have them live a “normal day” — sign in from a desktop, sign in from a laptop, add a backup key and run one recovery scenario. If that goes smoothly without ad-hoc exceptions, scaling usually becomes much calmer.

A realistic scenario and next steps

Company of 400 employees: a head office and 120 remote workers. There are 2–3 critical systems: corporate mail & calendar, VPN for internal resources and one business service (ERP or request portal). Goal for the first quarter: test passkeys and FIDO2 in real conditions and identify process changes.

Pick 30–50 people for the pilot: IT, finance, several managers and some remote staff. Their experience is typically most telling: many sign-ins, varied devices, and higher phishing risk.

The usual first week of a pilot

On Monday distribute hardware keys or enable passkeys on supported devices and run a 20-minute hands-on training. Make sure people sign in themselves immediately rather than just watching.

Midweek the first incidents appear. Usually these are small: a user doesn’t realise sign-in is confirmed on their phone; a remote worker has no backup; some users run old app versions that reject the new method. With a designated support channel and clear rules these do not escalate.

By Friday you’ll see what to tweak: where SSO or client updates are needed, which roles need stricter requirements, how many tickets are recovery-related, and which instructions are actually useful to people.

How to measure results and next moves

Look beyond “how many people enabled keys” to how it works live. Useful metrics: reduction in successful phishing attempts (without a key sign-in fails), fewer password resets, and support time spent on recovery.

Next steps usually are: expand the pilot to critical groups (finance, admins, managers), connect the most important systems, then progressively restrict passwords. For example: first disable passwords for external access (VPN, mail), then internal apps, and finally keep passwords only as an emergency fallback under strict procedures.

If you lack time to assess apps, configure SSO, and exercise recovery, an integrator can help. In Kazakhstan such projects are often easier when combined with endpoint and server refresh: GSE.kz, as a manufacturer and systems integrator, can supply corporate workstations and servers, integrate the infrastructure and support the pilot so it doesn’t rest on one or two enthusiasts.