Migrate from RSA SecurID to privacyIDEA: what moves and what does not
The core change in a move from RSA Authentication Manager to privacyIDEA is re-enrolling users on new tokens, not importing existing SecurID seeds. privacyIDEA's import formats cover SafeNet XML, OATH CSV, Yubikey CSV and PSKC files, but SecurID seed records are not among them, so the team should plan to issue fresh authenticators and retire the old ones on a schedule it controls. What can move is the user population itself: privacyIDEA reads users from existing stores through its user ID resolvers, including LDAP and Active Directory, SQL, SCIM and HTTP resolvers, so directory-backed identities usually do not need to be rebuilt by hand. The work is normally run by the identity or security engineering team, often with an implementation partner that handles the installation, configuration and cutover plan. Token enrollment is the visible part, but the larger effort and risk usually sit in the integrations. Every RADIUS client (VPN concentrators, remote access gateways and similar devices) must be pointed at privacyIDEA, and any RSA agents on Windows or web servers must be replaced with privacyIDEA's own integrations, such as the Windows credential provider, the PAM module on Linux or the REST API for web applications. Inventory these clients before enrollment starts, because each one has its own configuration and test window. Confirm three things with the vendor and in your own environment before setting a date: which SecurID token types are in circulation and how each user authenticates today, which integrations depend on RSA agents or RADIUS shared secrets, and how long both systems must run in parallel for users who have not yet enrolled. A practical approach is to keep Authentication Manager active until every RADIUS client and agent has passed testing on privacyIDEA, then retire tokens in waves. Ask any partner for a written scope that lists each integration, its test plan and its rollback step.
Which SecurID capabilities map to privacyIDEA, and where rework is needed
This table maps the main RSA SecurID capabilities to their privacyIDEA equivalents and marks each row as clean, needs rework or gap. Read it before scoping a migration, because the rework column shows where enrollment, client repointing or agent replacement will take planning time. The main takeaway is that token seeds cannot be carried over, so every user needs a new authenticator.
| Capability | privacyIDEA equivalent | Status and notes |
|---|---|---|
| Hardware and software token authentication | OATH tokens (TOTP, HOTP) and hardware token import from supported seed formats | Needs rework. SecurID seed files cannot be imported into privacyIDEA, so tokens are reissued to each user. |
| Software authenticator apps | Standard TOTP apps and the privacyIDEA Authenticator app | Clean for TOTP. Users of standard TOTP and HOTP can keep apps such as Google Authenticator. |
| Push approval | Push notifications through the privacyIDEA Authenticator app | Needs rework. Push requires the privacyIDEA Authenticator app, so users must install and enroll it. |
| FIDO2 and hardware keys | FIDO2 and WebAuthn passkeys and hardware keys | Clean for supported keys. Confirm that the target applications accept the keys your users already hold. |
| RADIUS for VPNs and network devices | RADIUS integration for VPNs such as OpenVPN, Fortinet and Palo Alto | Needs rework. Each RADIUS client must be repointed and tested, and shared secrets and attribute mappings checked. |
| Windows and web server agents | Windows credential provider, PAM module for Linux, REST API for web applications | Gap for agents. Replace each agent with the matching privacyIDEA integration, which needs separate design and testing. |
| User directory sourcing | User ID resolvers for LDAP and Active Directory, SQL, SCIM and HTTP stores | Clean where the directory already exists. Confirm the resolver setup against your current user store. |
| Self-service enrollment | Enrollment workflows and registration codes within privacyIDEA | Needs rework. Enrollment policies and user communication must be rebuilt, and both systems may run during the transition. |
Which data moves, which tokens are reissued, and which integrations get rebuilt
A SecurID to privacyIDEA move splits into four workstreams with different owners and different risks. User records are the easiest to carry across, token seeds are the hardest, and every RADIUS client and agent needs an explicit decision. Work through the cards in order, because the token decision shapes the enrollment plan.
User records from LDAP or Active Directory
If your SecurID users are sourced from Active Directory or LDAP, privacyIDEA can read them through its LDAP user ID resolver, so the identity data itself does not need a bulk export. Confirm which attributes SecurID uses for user IDs and whether any SecurID-only user records, such as local accounts or group mappings, exist outside the directory. Those local records must be recreated by hand or through the flat file, SQL or HTTP resolvers.
Token seeds and the SecurID gap
SecurID seeds are not an import format for privacyIDEA. privacyIDEA imports SafeNet XML, OATH CSV, Yubikey CSV and PSKC files, so confirm with RSA and your own administrators whether your SecurID hardware or software tokens can be exported in one of those formats. If no export exists, plan to issue new tokens. Do not assume seed export is possible without written confirmation from RSA.
Reissuing tokens to users
For tokens that cannot be imported, every user enrolls a new authenticator in privacyIDEA. Standard TOTP and HOTP apps can be used by those who prefer them, while push needs the privacyIDEA Authenticator app. Decide which token types are permitted for each user group, then count users who still hold physical SecurID fobs, since returning and retiring those devices needs its own checklist.
RADIUS clients that must be repointed
VPNs, firewalls and other network devices that send RADIUS requests to Authentication Manager must be pointed at the privacyIDEA RADIUS endpoint, with shared secrets set and tested per client. Build an inventory of every RADIUS client, including devices that were configured years ago and rarely log in. Test each one with a pilot user before changing the production configuration.
Agents replaced by native integrations
SecurID agents for Windows and web servers do not carry over. Replace them with the privacyIDEA Windows credential provider for logon, the PAM module for Linux, identity provider plugins such as Keycloak or AD FS where federated sign-in is used, and the REST API for custom web applications. Each replacement needs its own test plan, because authentication flows differ from the agent model.
Running both systems during enrollment
Keep Authentication Manager available until every user and client has been verified on privacyIDEA. During that overlap, decide which system handles each integration and document the fallback path if a privacyIDEA component fails. Confirm the cutover order with your help desk, because users who lose access during a partial migration will call before any dashboard shows a problem.
The migration sequence from inventory to decommission
The sequence moves a SecurID estate to privacyIDEA in controlled stages, so each group of users and each RADIUS client is proven on the new system before the old one stops answering. Every step ends with a written artifact that the next step depends on.
Inventory tokens, clients and agents
Export the list of SecurID tokens from Authentication Manager, along with their assigned users, token types and status, and record every system that calls it: RADIUS clients such as VPN concentrators and firewalls, Windows and web server agents, and any scripts or APIs. Build a client register with the owner, protocol, configuration location and change window for each entry. This step is done when every client that authenticates against Authentication Manager appears in the register and the owner of each has confirmed it. Also record which tokens are hardware fobs, because those will need replacement issuance rather than import.
Confirm the target user store and token plan
Connect privacyIDEA to the directory that holds your users through a user ID resolver, such as LDAP or Active Directory, and confirm that the attributes needed for login match what the clients send. Decide which users move to which token type, for example push or FIDO2 for staff and hardware OTP for a small group that cannot use phones. Note that SecurID seed files are not among privacyIDEA's import formats, so existing hardware tokens will be reissued as new tokens. The output is a token plan and a resolver test report showing successful lookups for sample accounts.
Run a pilot with a small user group
Enroll a small group of volunteers in privacyIDEA, have them authenticate through one non-critical RADIUS client or application, and record every failure with its cause. Include at least one user on each token type you plan to offer, and test lockout, resynchronization and the help desk procedure for a lost token. Keep Authentication Manager as the primary path for everyone else. The pilot exit report should list the defects found, their fixes, and a decision from the sponsor on whether the enrollment process is ready for wider use.
Run both systems in parallel during enrollment
Point the wider user population at privacyIDEA for enrollment while Authentication Manager continues to answer for existing tokens. Users keep their current SecurID fob or software token until they have enrolled their new authenticator, which allows the help desk to fall back during the transition. Track enrollment status per user and per client, and watch authentication logs on both systems so that any user who stops logging in is caught early. The step closes when every user in the plan has an active privacyIDEA token and the enrollment report matches the inventory.
Phase RADIUS client cutover using a runbook
Move RADIUS clients to privacyIDEA one group at a time, starting with the lowest-impact systems in the client register. For each client, change the RADIUS server address and shared secret, test with a known account, and confirm the access log entries on the privacyIDEA side. Write the steps in a cutover runbook that names the owner, the rollback action and the verification check for each client, and reuse it for every group. Agents for Windows logon and web servers need replacement components, since they are not carried over from SecurID, so schedule them with the owners of those systems. Each cutover is complete when its test passes and the client register shows the new target.
Retire Authentication Manager and archive audit logs
After every client in the register has been cut over and no authentications have reached Authentication Manager for a period your security team sets, stop its services and revoke the remaining tokens. Before shutdown, export the audit logs, token assignment history and configuration that your compliance program requires, and store them in an archive the retention policy can reach. Confirm with your compliance and records owners which archive format and retention period apply, because these depend on your own obligations. The decommission is complete when the archive has been verified, the license and support contract is closed, and the change record is signed off.
What drives cost and duration in a SecurID to privacyIDEA move
This table lists the factors that most change the effort of moving from RSA Authentication Manager to privacyIDEA, why each one adds work, and how to keep it contained. Read it as a checklist to size your own inventory before asking for a fixed-scope quote, since no duration is implied by these rows.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| RADIUS clients and VPNs | Each VPN concentrator, firewall or network device stores the RADIUS server address and shared secret, and each one needs a test login before cutover. | Inventory every RADIUS client first, group identical platforms, and repoint them in batches with a rollback path for each batch. |
| Windows and web agents | SecurID agents for Windows and web servers are replaced by privacyIDEA integrations such as the Windows credential provider and REST-based web integrations, so each host needs its own install and test. | Count agents by host and application, retire unused ones, and standardize on a small set of integration patterns. |
| Users needing reenrollment | SecurID seeds cannot be imported into privacyIDEA, so every hardware token holder must receive and register a new token or authenticator. | Sort users by token type and role, use self-service enrollment where policy allows, and schedule waves to limit help desk peaks. |
| Hardware token logistics | Old fobs must be collected, tracked and destroyed or stored, and replacement hardware or app choices must be procured and shipped where needed. | Confirm stock levels and shipping lead times early, decide whether software tokens cover most users, and set a return or disposal process. |
| User directory complexity | privacyIDEA reads users through resolvers such as LDAP, SQL or SCIM, so duplicate accounts, mismatched attributes or multiple directories add mapping work. | Clean up identifiers and group membership before migration, then test resolver lookups for a sample of each user population. |
| Run-both-systems period | Running SecurID and privacyIDEA side by side means two sets of policies, support steps and audit logs until enrollment completes. | Define a cutover date per group, document which system is authoritative for each user, and agree a retirement checkpoint in writing. |
| Integration testing | Each RADIUS client, agent and identity provider plugin has its own login flows, error cases and failover behavior to verify. | Build a test matrix from the inventory, include failure and lockout cases, and get sign-off from application owners before each wave. |
| Evidence for assessors | Auditors may ask for change records, token inventories and test results covering both systems during the overlap. | Keep migration logs, test evidence and approvals in one repository from the start. Confirm required evidence with your auditor. |
How the migration changes by estate size and starting point
An estate where SecurID mainly protects VPN concentrators or firewalls over RADIUS is the simplest starting point, because the change is confined to the RADIUS clients and the token records. privacyIDEA exposes a RADIUS server that VPNs such as OpenVPN, Fortinet and Palo Alto can use, so the work centers on pointing each device at the new server and proving that the same users can sign in. Because no agent runs on the protected systems, the cutover is mostly a configuration exercise at the network edge.
- Inventory the RADIUS clients: List every device, its shared secret, the group of users it accepts and the token types in use.
- Configure a parallel RADIUS policy: Set up the same user groups and token policies in privacyIDEA before changing any device.
- Pilot on one gateway: Point a single VPN concentrator at privacyIDEA for a small group of users and test login, failure and lockout behavior.
- Keep the old path available: Retain the SecurID RADIUS configuration on each device until the pilot group has signed in successfully over a sustained period.
- Test failure handling: Confirm what happens when privacyIDEA is unreachable and that the device fails closed.
Before you start, confirm with your VPN vendor how each device handles RADIUS challenges and new-PIN prompts, since these behave differently across products.
An estate with many SecurID agents on Windows servers, Linux hosts and web servers needs more work than a RADIUS-only setup, because each agent integration must be replaced by a privacyIDEA integration. privacyIDEA covers these cases through a PAM module for Linux, a credential provider for Windows logon, and its REST API for web applications, so each agent type maps to a different component. The order of work should follow the application risk and the number of hosts in each group.
- Map each agent to its replacement: Record which systems use Windows logon, PAM, web server modules and custom code, and assign the matching privacyIDEA component to each.
- Group hosts by platform: Migrate one platform at a time so that testing and rollback procedures can be reused.
- Build a pilot per platform: Test interactive logon, remote access, service accounts and scheduled tasks on a non-production host of each type.
- Handle custom code separately: Applications that call the SecurID agent API directly need code changes that are scoped and tested individually.
- Plan the agent removal: Remove the SecurID agent only after every dependent host has been verified and its rollback path is no longer needed.
Ask your team to list every system with an agent installed, since agents are often forgotten on older servers and batch hosts.
An estate with many physical SecurID fobs has the most important constraint in the migration. privacyIDEA's import formats do not include SecurID seed files, so seeds cannot be carried over from Authentication Manager. Each user will need a new token enrolled in privacyIDEA, which changes the enrollment effort and the user communication far more than the server work. The hardware inventory also affects what replaces the fobs, since privacyIDEA supports several token types beyond physical OTP devices.
- Count and classify tokens: Separate active fobs, spares, lost or retired tokens, and tokens assigned to service or shared accounts.
- Choose replacement token types: Decide which users move to push, TOTP through a standard app, FIDO2 keys or other options, and which keep a hardware OTP option.
- Plan enrollment waves: Enroll users in groups so that help desk capacity matches the number of users changing tokens at once.
- Run both systems during enrollment: Keep SecurID active for users who have not yet enrolled so that no one loses access.
- Decommission fobs last: Retire the old tokens only after the enrollment period ends and the records show no active use.
Confirm with your vendor and your own records which token formats you hold, since the import rules apply to seed files you can export, not to the fobs themselves.
An environment that already stores users in Active Directory or LDAP can keep those directories as the source of truth. privacyIDEA reads users through LDAP resolvers, including Active Directory, so user accounts, group membership and passwords do not need to be copied into a new store. The migration then focuses on token assignment and on the authentication path, rather than on identity data. Confirm the resolver configuration and the attributes privacyIDEA needs before enrolling anyone.
- Connect the resolver read-only first: Configure the LDAP resolver with a service account that can read the required attributes and test lookups before any token is assigned.
- Validate group and attribute mapping: Check that the groups used for token policies match the directory groups that already control access.
- Test with real directory accounts in a pilot group: Use accounts from different OUs and nested groups to confirm that resolution works as expected.
- Verify disabled and expired accounts: Confirm that a disabled directory account cannot authenticate through privacyIDEA.
- Coordinate with the directory team: Agree on change control for the service account, the bind credentials and any LDAP over TLS settings.
Before you begin, check whether SecurID currently reads from the same directory, since mismatched user sources cause the most confusing login failures.
What usually goes wrong and how to prevent it
Most failed SecurID to privacyIDEA moves fail on assumptions made early: that seeds carry over, that clients will simply follow a new server, or that the fallback path works. The cards below name each risk and the check that prevents it, so the cutover can be rehearsed before any user depends on the new system.
Assuming seeds can be imported
privacyIDEA imports seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats, but SecurID seeds are not among them. Teams that plan a seed export from Authentication Manager and expect users to keep their existing tokens will find the plan blocked late in the project. Confirm with RSA and your own records which hardware tokens and software tokens are in use, then budget for new token issuance and a user communication plan before the cutover date is set.
Lockouts during reenrollment
When users must enroll new tokens, anyone who loses a device or misses the enrollment window can be locked out of VPN, SSH or admin access. Privileged accounts are the most damaging to lose. Pilot enrollment with a small group, keep a documented helpdesk procedure for identity verification before a token is reset, and confirm that at least two administrators can reach privacyIDEA without relying on a newly enrolled token.
RADIUS settings wrong after repointing
Each VPN, firewall or network device stores a RADIUS server address, shared secret, port and timeout. A mismatched shared secret typically causes authentication to fail silently for every user, and an aggressive timeout can drop logins under load. Inventory every RADIUS client before cutover, record its current settings, and test one client at a time against a privacyIDEA test account, including the failover behavior when the primary server is unreachable.
Agent gaps for Windows and web servers
SecurID agents for Windows logon and web servers do not map one-to-one to privacyIDEA components. privacyIDEA provides a Windows credential provider, a PAM module for Linux and a REST API for web applications, and it can act as an identity provider plugin for AD FS, Keycloak and Shibboleth. Build a matrix that lists each system protected by an agent today, the privacyIDEA integration that replaces it, and any system with no equivalent that needs a different design.
Untested fallback paths
Teams often assume that a second system, a bypass account or a paper recovery process will work during an outage, and discover otherwise during an incident. Test each fallback before cutover: privacyIDEA service failure, a lost RADIUS path, a database restore and a user who has no working token. Record who may invoke each fallback and how it is logged, and keep the Authentication Manager tenant available in read or fallback mode until those tests pass.
Losing audit history
Authentication logs in Authentication Manager support investigations, compliance evidence and access reviews, and a new system does not carry them over automatically. Export the existing logs and retain them under your normal retention policy before decommissioning. Then confirm that privacyIDEA logs reach your SIEM with the fields your auditors ask for, such as user, token serial, result and source client.
Questions buyers ask before migrating from SecurID to privacyIDEA
How much effort and cost does a SecurID to privacyIDEA migration involve?
The cost is driven by scope, not by a single fixed figure, and it falls into a few components: the design and build of the privacyIDEA servers, the user store and policy work, the reissue of tokens, the repointing of RADIUS clients and agents, and the parallel running period. Costs that recur are the servers and their hosting, the time your team spends on upkeep, any optional NetKnights Enterprise Edition support, and any new authenticators you buy. Ask for a quote that lists each component separately, states who performs each task, and shows which items are one-time and which recur. The total is set by how many users, token types and RADIUS clients you have, so ask for a per-component breakdown rather than a single number.
How long does a SecurID to privacyIDEA migration take?
The pace is set by the number of users who must enroll, how many RADIUS clients and agents must be repointed, and how long you choose to run both systems side by side. Token reissue is usually the slowest part because each user must enroll a new authenticator, and a coordinated rollout across departments takes longer than a pilot group. Other drivers include change approval windows, testing against each VPN, firewall or application that uses RADIUS, and the availability of your change and service desk staff. Ask any vendor or partner for a written schedule tied to the phases in your scope and to the number of users in each wave.
What does the migration need from our own team?
Your team supplies the decisions and access that only your organization can give. Typically this includes the user directory or LDAP and Active Directory access that privacyIDEA will read through its user ID resolvers, an inventory of RADIUS clients and their configuration, the list of applications and servers that use the RSA Windows or web agents, and a named owner for policies such as token types, lockout and enrollment rules. You will also need a change window, a help desk script for enrollment, and sign-off on the cutover plan. Confirm with the implementation partner exactly which of these tasks sit on your side before work starts.
Can our own staff run this migration in-house?
Yes, many teams can do this internally if they have Linux administration skills, experience with LDAP or Active Directory, and a working knowledge of RADIUS and PAM. privacyIDEA is documented for installation with pip and on Ubuntu and CentOS or RHEL-family systems, so the server build is within reach of a capable operations team. The harder parts are usually the token reissue campaign, the agent replacements on Windows and web servers, and testing every RADIUS integration before cutover. Consider the team's capacity during the parallel running period, because an in-house project can stall when operations work takes priority. A fixed-scope partner engagement is one option if you want that work defined and delivered in writing.
Can we import our existing SecurID hardware tokens into privacyIDEA?
No. SecurID seeds are not among the seed formats privacyIDEA imports, so existing RSA hardware tokens cannot be moved across. privacyIDEA imports seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats, and the OATH CSV format covers HOTP, TOTP, OCRA and TAN tokens. In practice, you issue new tokens, such as TOTP or HOTP apps, FIDO2 keys, push through the privacyIDEA Authenticator, or hardware OTP tokens from a supported vendor, and enroll each user. Plan the reissue and the return or disposal of old fobs as a separate workstream, and confirm current import support with privacyIDEA documentation before you design around any format.
What happens to our existing RADIUS integrations during the move?
Each RADIUS client, such as a VPN concentrator or firewall, must be pointed at the privacyIDEA server and configured with its shared secret and authentication settings. privacyIDEA integrates with VPNs such as OpenVPN, Fortinet and Palo Alto through RADIUS, so the change is mostly a configuration task on each client rather than a rebuild. Test each one with a pilot user before cutover, because the response and challenge behavior of your device must match what your users expect. Keep the SecurID servers available as a fallback until each client has passed testing. Inventory every client first, since undocumented devices are the most common source of delays.
Which parts of the old setup need replacing, not repointing?
Repointing covers RADIUS clients, but the RSA agents for Windows logon and web servers have no direct equivalent. privacyIDEA offers a PAM module for Linux, a credential provider for Windows logon, and a REST API for web applications, so each agent-based system needs its own replacement plan. Identify which applications use the SecurID agent, which use RADIUS, and which call a SAML or OIDC endpoint, and plan each path separately. Confirm the exact plugin and version for each platform with the privacyIDEA documentation before you schedule the change.
Should we run SecurID and privacyIDEA side by side, and for how long?
Running both systems during enrollment is the safer approach for most organizations, because users can fall back to their existing method while they enroll on privacyIDEA. Parallel running adds cost, since you keep RSA licenses, appliances or cloud service and the privacyIDEA servers active at the same time. The length of the overlap depends on how quickly users enroll and on how many clients you have not yet repointed. Define exit criteria in advance, such as the percentage of users enrolled and the clients tested, and agree on the date you decommission RSA with your security and audit owners.
How DeployOpen scopes and runs a SecurID to privacyIDEA migration
DeployOpen plans, implements, integrates, hardens and documents self-hosted privacyIDEA inside the client's own infrastructure, whether that is their cloud account, data center or air-gapped network. Most engagements are fixed-scope, so the written agreement should name the components in play before any work starts: the privacyIDEA servers, the user ID resolvers that replace the SecurID user store, the RADIUS clients being repointed, the Windows and web server integrations that need new agents or plugins, and the token types each user group will receive. The scope should also state who owns the decision on token policy and who signs off on cutover. Ongoing support, upgrades and continuous testing are available as a retainer, which is worth considering if the organization wants someone to handle privacyIDEA releases after the parallel run ends.
A quote follows from that written scope, so the more precisely the inventory is done, the more useful the quote. Ask the vendor-independent questions first: how many RADIUS clients and agent-protected hosts exist, which SecurID seed files are still on hand and which users have no usable token, and which identity sources feed the directory. DeployOpen can prepare the evidence a compliance assessment will look at, such as configuration baselines, access control records, change logs and test results. It does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, so the migration plan should agree early with your auditor which artifacts they will accept.
