RSA SecurID tokens to passwordless MFA with passkeys
Cohash moves workforce MFA from RSA SecurID one-time codes to phishing-resistant passkeys and FIDO2 security keys. We inventory every RADIUS client, agent and token, enroll users group by group in the identity provider's passkey policy, enforce passkeys with authentication strength rules, and keep Authentication Manager only for the VPN, network and server logons that can't use FIDO2 yet.
- 01Inventory every place a code is typed
- 02Split by what can use FIDO2
- 03Passkey policy and enrollment
- 04Enforce, then retire tokens
- 05Recovery and break-glass
The story
Told without the client's name or anything that could identify them.
An insurer's identity team had SecurID hardware tokens expiring in batches and Authentication Manager on 8.7, with two upgrade hops through 8.8 before 8.9. Staff typed one-time codes that a phishing page could relay, and admins used the same token for VPN, servers and cloud consoles. We listed every RADIUS client, agent and integration first and split them by whether they could use FIDO2. Browser and desktop sign-in moved to passkeys in Entra ID group by group, tokens were retired against their expiry dates, and Authentication Manager now serves only the VPN and server logons that still need it.
why it was urgentRSA lists primary support for Authentication Manager 8.7 SP2 ending in January 2027, and 8.9 upgrades only from 8.8, so many sites face two upgrade hops anyway. Microsoft Entra ID now supports synced and device-bound passkeys in every edition, including Free, and NIST published SP 800-63B-4 in July 2025.
- openHardware tokens expire in batches and the renewal quote is on someone's desk.
- recurringAuthentication Manager runs 8.7 and the route to 8.9 goes through 8.8.
- blockedUsers type six-digit codes that a phishing page could relay in real time.
- openAdmins use the same token for VPN, server logon and cloud consoles.
The estate, before and after
Before: one-time codes for every sign-in
Staff and admins typed SecurID codes into Entra ID, the VPN and server logons, and each one checked the code with Authentication Manager. A phishing page could relay that code and it worked just as well.
After: passkeys in Entra ID, RSA kept for RADIUS only
Staff and admins sign in to cloud and desktop apps with passkeys, through Entra ID passkey profiles. Authentication Manager is left serving only the VPN and server logons that can't use FIDO2 yet.
How we run it, phase by phase.
5 phases take you from RSA SecurID tokens and Authentication Manager to Passkeys and FIDO2 security keys. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Inventory every place a code is typed
Find every RADIUS client, Windows and Unix MFA agent, Web Tier portal, Admin SDK script and cloud app that calls Authentication Manager. Then list the tokens, with type, expiry date and the person holding each one.
- phase 02
Split by what can use FIDO2
Browser and desktop sign-ins through Entra ID, Okta or Ping move to passkeys. VPN and network devices that only speak RADIUS stay on RSA, or move to a VPN that supports SAML or OIDC sign-in, and get their own plan.
- phase 03
Passkey policy and enrollment
Set passkey profiles so admins use device-bound keys with attestation, and other groups may use synced passkeys if policy allows. Register users while their SecurID token still works. Entra asks for a recent MFA before passkey registration, and that token is how they'll pass it.
- phase 04
Enforce, then retire tokens
Apply a phishing-resistant authentication strength policy one app at a time. Revoke each group's tokens as it's enforced, timed against the expiry dates, so nobody renews a batch by accident.
- phase 05
Recovery and break-glass
Design lost-key and new-phone recovery with identity proofing, and give break-glass accounts FIDO2 keys kept offline. This is the bit most passwordless rollouts get wrong, so test it before go-live.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Staff sign in with passkeys instead of six-digit codes
Browser and desktop sign-ins through Entra ID need a phishing-resistant authentication strength now. We enforced it app by app as each group finished enrolling.
- result 02
Admins hold device-bound keys with attestation
Privileged users sign in with FIDO2 security keys on hardware we know about. Synced passkeys are only allowed for groups where policy permits.
- result 03
No token batch was renewed by accident
Tokens were revoked group by group as enforcement went live, timed against the expiry dates in the inventory. The renewal quote only covers what stays on RSA.
- result 04
Recovery is as strong as sign-in
Lost-key and new-phone recovery runs through identity proofing, and break-glass accounts have offline FIDO2 keys. We tested both before go-live.
- result 05
RSA has a smaller, defined role
We listed the RADIUS clients and server logons that can't use FIDO2 yet, with a plan for each. In parallel, Authentication Manager goes to 8.8 and then 8.9.
Risks we plan for
-
RADIUS-only systems
VPN concentrators, network gear and some Unix logons can't do FIDO2. They need RSA, a different authenticator or a product change, and they're often the long tail.
-
Recovery becomes the attack path
If one help desk call can reset a passkey, that's the call attackers will make. Recovery has to be as strong as sign-in.
-
Synced passkeys and attestation
Microsoft points out that synced passkeys don't support attestation and should be handled like other unattested authenticators. For admins that settles it. They get device-bound keys.
-
Shared and kiosk devices
Shift workers on shared terminals can't leave a passkey on the device. Site by site, we decide between security keys and a separate kiosk sign-in flow.
Where AI helps, and where it needs guardrails
Enforcement here lives in Entra ID passkey profiles and authentication strengths, and RSA ID Plus has passwordless options of its own for teams staying with RSA. Automation needs separate handling. Agents don't hold passkeys, so admin accounts used by scripts or MCP servers move to workload identities with scoped credentials, and the token seed sitting in a script goes away.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Inventory of RADIUS clients, agents, integrations and tokens with expiry dates
yours to keep - design02
Passkey profile and authentication strength policy design per user group
yours to keep - plan03
Enrollment and token retirement schedule by group
yours to keep - tests04
Recovery and break-glass procedure, tested
yours to keep - plan05
Plan for the RADIUS and server logons that stay on RSA
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01attestation
- Evidence a machine can verify, like a TPM-held key or a signed build record. SPIRE checks it for the node and the process before it issues an identity.in context →
- 02Rules
- The JavaScript snippets Auth0 used to run at login. Someone would write one to add a role to the token or block a sign-in, and each one ran after the last.in context →
- 03RADIUS
- An old network sign-in protocol often used to connect reps to token or MFA servers. BeyondTrust removes it in 27.1.in context →
- 04Break-glass accounts
- Emergency admin accounts excluded from normal access policies. You only use them when everything else has failed, and you watch them closely.in context →
- 05FIDO2
- What sits behind hardware security keys like a YubiKey. You touch the key, and it can ask for its own PIN or your fingerprint first.in context →
- 06SAML
- What sits behind most single sign-on. Entra ID or Okta signs a message saying who you are, and Secret Server lets you in because it trusts that signature.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Can we drop RSA entirely?
It depends on your VPN, network devices and server logons. Browser and desktop sign-in usually moves cleanly. Anything RADIUS-only needs RSA, a replacement authenticator or a product upgrade, and each goes on our list.
02Synced passkeys or device-bound security keys?
Both, usually. Synced passkeys are easier for most staff. For administrators and high-risk roles we prefer device-bound keys with attestation, because then you know exactly which hardware holds the key.
03What does it cost?
There's no extra license for passkeys in Entra ID. What you pay for is security keys where you choose them, help desk time during enrollment and the work on systems that stay on RSA. We size each from the inventory.
04Should we upgrade Authentication Manager first?
If any tokens stay in use past January 2027, for VPN or servers, then yes. We run the 8.8 then 8.9 upgrade in parallel with the passkey rollout so one never holds up the other.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyMoving Auth0 Rules and Hooks to Actions before Auth0 switches them off
Moving Auth0 Rules and Hooks to Actions before Hooks stop on 30 April 2027 and Rules on 31 January 2028, with token claims checked before and after each change.
read the case studyec5ce66c - 01Book a 30-minute working sessionsenior engineer
- 02Talk to an engineer about your setupreply within 24 hours
- 03See how similar projects wentcase studies
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it