When RSA SecurID fits and when privacyIDEA fits
If you are renewing or reconsidering RSA SecurID, the choice usually comes down to whether your estate is built around SecurID hardware tokens, RSA agents and a vendor support contract, or whether you want self-hosted MFA with a wider range of token types under the AGPLv3 license. RSA SecurID fits organizations that have standardized on RSA Authentication Manager and its agents and that value a single vendor to call. privacyIDEA fits teams that want MFA running entirely in their own infrastructure, with push, FIDO2, TOTP, HOTP, PIV smartcards and SMS or email options in one platform, and that can own the operations work themselves or buy it from a partner.
Four factors should drive the decision. The first is your existing token seeds: privacyIDEA imports seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats, but confirm with privacyIDEA's import documentation whether your SecurID seed records fit any of them before assuming a seed transfer is possible. The second is agent dependencies: list every Windows logon, web server and VPN that talks to Authentication Manager, because each one needs a replacement path, such as the PAM module, the Windows credential provider or RADIUS. The third is your user store, since privacyIDEA reads users through LDAP, SQL, SCIM, HTTP and flat file resolvers and your directory must be reachable from it. The fourth is in-house skill and support model: decide early whether your team will run privacyIDEA on Linux packages or pip installs, or whether you need a partner and the optional NetKnights Enterprise Edition.
Which option fits which scenario
This table maps common RSA SecurID situations to the option that usually fits better, with the condition that drives the choice. Read each row against your own estate, because the right answer often depends on one or two constraints such as existing tokens, agent dependencies or where your users are stored.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Existing SecurID hardware token fleet | Keep SecurID for now, or re-issue to privacyIDEA | Whether your seeds can be exported; privacyIDEA's supported import formats do not include SecurID seed files, so confirm with RSA and your own records |
| RADIUS-only VPN estate | privacyIDEA | RADIUS clients such as OpenVPN, Fortinet and Palo Alto are covered by privacyIDEA's RADIUS integration; confirm your exact firmware and RADIUS attribute needs |
| Windows logon and web server agents | Depends on agent dependencies | privacyIDEA uses a Windows credential provider and a REST API; if you rely on RSA agents for specific web servers, check that a plugin or API path exists for each one |
| Linux and SSH logon | privacyIDEA | Its PAM module and SSH key token type cover this without a separate agent; confirm your distribution and PAM stack |
| FIDO2 or passkey rollout | privacyIDEA | Its FIDO2 and WebAuthn support covers hardware keys and passkeys; confirm the authenticator models your users need |
| Push-based approval | privacyIDEA, with the privacyIDEA Authenticator app | Push requires the privacyIDEA Authenticator app; standard TOTP and HOTP apps cannot receive push, so plan app distribution |
| LDAP or Active Directory user base | privacyIDEA | Its LDAP resolver reads from Active Directory and other LDAP services without moving the user store; validate attribute mapping and bind accounts first |
| Air-gapped network | privacyIDEA (self-hosted, installed from packages or pip) | Because all components run inside your network, confirm that required Python and OS packages can be mirrored into the enclave |
Where authentication data lives and who controls it
Authentication data is more sensitive than most application data because it holds seeds, token state, user identifiers and audit trails. The four cards below cover where that data sits, how each hosting model changes control, what compliance teams will ask for, and how seeds and keys move during a migration.
Data location: on premises or RSA cloud
RSA Authentication Manager runs on infrastructure you operate, while RSA also offers a cloud service. Confirm with RSA exactly which records, logs and token state sit in each deployment option, and which of them leave your network under a cloud contract. Ask where backups are stored, who holds the administrative keys, and which regions host any hosted component. Write these answers down before you compare them with privacyIDEA.
privacyIDEA keeps user data in your infrastructure
privacyIDEA describes itself as a self-hosted MFA platform that keeps user data inside the operator's infrastructure. Its database, token records and audit data live on servers you choose, and it reads users from your existing directories rather than copying a separate identity store. Confirm the database placement, backup targets and log forwarding in your own design, because the platform does not decide those for you.
Appliance versus Linux package hosting
Authentication Manager is delivered with its own operating system and appliance-style lifecycle, so patching and upgrades follow RSA's release path. privacyIDEA is installed on operating systems you already manage, using pip or packages for Ubuntu and CentOS or RHEL-family systems. This shifts operating system patching, hardening and monitoring to your team. Check which OS versions your security baseline permits and who owns the patch schedule.
Compliance evidence without attestation
Auditors will ask how authentication logs are protected, who can change token policies and where evidence of those controls is kept. DeployOpen can prepare systems, configuration baselines and evidence for your assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Agree the evidence list with your assessor before the build starts.
Seed and key custody during migration
Hardware token seeds are sensitive secrets that must never be exposed in transit or left in working folders. privacyIDEA can import several seed file formats, including GPG-encrypted files, but RSA SecurID seeds are not among its supported import formats, so existing SecurID tokens generally need reissuing. Define who generates, holds and destroys any seed material, where the GPG key is stored, and how the old records are retired after cutover.
What happens to existing SecurID tokens
privacyIDEA cannot take over existing SecurID seeds from the supported import formats, so plan for new tokens rather than a direct transfer. The token import function accepts SafeNet XML, OATH CSV, Yubikey CSV and PSKC seed files, and it can read GPG-encrypted seed files encrypted with its own GPG key. SafeNet XML is the format most likely to look familiar to a SecurID team, but it is a SafeNet format, not a guarantee that RSA SecurID seeds will load. Before the project starts, ask RSA in writing whether and how your seeds can be exported, in which format, and whether RSA will support that export on your hardware and software versions. If the answer is no, or the export is not in one of the accepted formats, every token must be enrolled fresh.
For a hardware fleet, the consequence is a physical and logistical one. Each fob or card that is not imported must be replaced or re-enrolled, and the old devices are retired only after the user has moved to the new credential. Hardware OTP tokens that privacyIDEA can import, such as OATH-compatible devices, keep working after import, while anything that cannot be imported needs a replacement method. Inventory the fleet by token type and serial number first, then decide which users keep a hardware token and which move to an app, a FIDO2 key or a smartcard.
For software or app-based users, the split is clearer. Users of standard TOTP or HOTP can keep an app such as Google Authenticator once their token is enrolled, so they only need to scan a new QR code. Users who rely on push approval need the privacyIDEA Authenticator app, because push notifications are not available through standard authenticator apps. Enroll these users before the cutover date and test push on a pilot group, since a user who cannot approve a push at the moment of cutover will be locked out of VPN or admin access.
Cost components on each side and what drives them
Total cost on each side is a set of separate components, some paid once and some every year. Comparing them line by line shows which costs an RSA renewal quote will carry forward and which costs move to your own budget with privacyIDEA.
RSA licenses and maintenance
Authentication Manager licensing and annual maintenance are the recurring core of the RSA side. Ask RSA for a written renewal quote that states the license basis (users, tokens or seats), the maintenance term, and what support tier is included. Confirm whether the quote covers agents, the cloud service or only the on-premises server. Growth in user count or a move to a different edition will change this line directly.
Hardware tokens and appliances
Hardware OTP fobs and any appliance or server hardware are a mix of one-time purchases and replacement cycles. Fobs are lost, damaged or expire, so replacement volume is a recurring cost driven by your user count and loss rate. Ask whether appliance refresh and support contracts are priced separately from the license.
Upgrade work and version changes
Moving Authentication Manager to a new release can require new operating systems, agent updates and certificate changes, all of which cost internal or partner hours. This is recurring in practice, because each major change restarts the effort. Estimate it by counting the agents, RADIUS clients and integrations you would need to retest before any upgrade is scheduled.
privacyIDEA servers and hosting
privacyIDEA is licensed under AGPLv3, so the software itself carries no license fee. You pay for the servers, load balancing, database, backups and certificates in your own infrastructure. These are mostly recurring infrastructure costs, and they scale with your authentication volume and high availability design, which you should size with your platform team.
Optional NetKnights Enterprise Edition support
privacyIDEA.org states that the Enterprise Edition is available from NetKnights. This is an optional recurring cost if you want vendor support, and it is separate from the open-source core. Ask NetKnights for a written quote that lists the support level, response commitments and any features included, and compare it with the internal skills you would otherwise need.
New authenticators and migration labor
Because SecurID seeds are not among privacyIDEA's import formats, moving users usually means issuing new tokens or app enrollments. Those authenticators are a one-time cost, and migration labor for enrollment, help desk support and parallel running is also one-time. Drivers include the number of users, the mix of hardware and app tokens, and whether you run both systems during rollout.
Operations staffing
Running privacyIDEA in-house means someone patches the Linux packages, monitors the service, rotates keys and handles token lifecycle requests. This is recurring staff time that replaces part of the RSA support spend. Ask yourself who owns on-call coverage and how many hours a month the role needs, then compare that with the support tier on the RSA quote.
How a move from SecurID to privacyIDEA is structured
The sequence moves authentication from RSA Authentication Manager to privacyIDEA in controlled stages, so each RADIUS client, agent and user store is switched over only after its replacement has been tested and a fallback path is confirmed.
Inventory RADIUS clients, agents and user stores
Your team lists every system that sends authentication requests to Authentication Manager: VPN concentrators, network devices, Windows and Linux hosts with agents, web servers and any application that calls the SecurID API. For each one, record the protocol used, the owner, the user population and the directory the users come from. The output is a signed-off inventory that shows which items depend on RADIUS, which depend on an agent and which read users from LDAP or Active Directory. Ask privacyIDEA's maintainers or NetKnights to confirm integration support for each item before you commit to a design.
Install privacyIDEA on Linux
Your platform or Linux administrators install privacyIDEA on hardened servers in your own infrastructure. The installation documentation covers pip and packaged installs on Ubuntu and on CentOS or RHEL-family systems, so the choice depends on your configuration management and support standards. Ask for the operating system versions you plan to use and confirm them against the current documentation. The step is complete when the service starts, the administrative interface responds on a test host and the database and backup configuration have been checked.
Connect LDAP or Active Directory resolvers
Your directory administrators configure privacyIDEA user ID resolvers that point at the same LDAP or Active Directory servers that SecurID currently reads. Use a read-only service account and test queries for a sample of users, including disabled and locked accounts. Confirm that usernames, group memberships and any realm mapping match what SecurID returns today. The step is complete when test users resolve to the same identities in both systems and the bind account has only the rights it needs.
Enroll new tokens for users
Your help desk and security team decide which token types replace each SecurID token: standard TOTP or HOTP through a common authenticator app, push through the privacyIDEA Authenticator app, FIDO2 keys or other options. Hardware OTP seeds from SecurID are not among privacyIDEA's import formats, so affected users are enrolled with new tokens and identity is verified under your existing process. Record which users enrolled, which token type they chose and how lost or replaced devices are handled. The step is complete when the enrolled population matches the agreed pilot group.
Repoint RADIUS clients and replace agents
Your network and application teams change each RADIUS client's server and shared secret settings to point at privacyIDEA, then test one device at a time. Windows logon and Linux PAM access use the privacyIDEA credential provider and PAM module, and web applications move to the REST API or identity provider plugins where they fit. Keep a documented rollback for each change. The step is complete when test logins succeed for each client type and the monitoring shows the expected authentication events in privacyIDEA.
Run both systems in parallel
For a defined pilot group, users authenticate through privacyIDEA while Authentication Manager remains available for everyone else and as a fallback. Your team tracks failed logins, help desk tickets, latency and any client that still depends on SecurID. Expand the group in stages only when the earlier stage shows no unresolved issues. The step is complete when every system in the inventory has a tested path through privacyIDEA and the fallback has been exercised successfully.
Decommission SecurID after confirming fallback
Once every client is migrated, your team confirms that no authentication still reaches Authentication Manager, then disables new logins there and keeps the final configuration, logs and token records under your records-retention policy. Hardware tokens are collected or retired according to your asset process, and the appliance or software is decommissioned after the retention period. Document the decision, the evidence of zero remaining traffic and the owner of the archived data. The step is complete when the change record shows the retirement was approved and the archive can be retrieved.
Questions buyers ask before choosing privacyIDEA
How much does it cost to switch from RSA SecurID to privacyIDEA?
The cost is set by components, not by a single price, and no RSA list price or privacyIDEA price is supplied here. The software license is the smallest item: privacyIDEA is licensed under AGPLv3, so there is no per-user license fee for the community edition. The recurring and one-time costs are the servers or virtual machines, the new authenticators, migration and integration work, and operations staff time. Ask any quote to separate one-time work (design, migration, integration with RADIUS clients, agents and identity providers) from recurring work (patching, upgrades, monitoring, backups and support). If you want vendor support, ask whether it is the optional NetKnights Enterprise Edition, which is available from NetKnights, and what it covers. Your own SecurID renewal terms and hardware token counts will set the comparison.
How long does a SecurID to privacyIDEA migration take?
The timeline depends on how many systems authenticate through SecurID, how many users must enroll new tokens, and whether you run both systems during the transition. No duration is supplied for this migration, so treat any number you hear as something to verify against your own inventory. The main drivers are the count of RADIUS clients to repoint, the number of Windows and web server agents to replace, and the user population that must enroll new authenticators. SecurID seed files are not among privacyIDEA's import formats, so hardware tokens are typically replaced rather than carried over, which adds enrollment time. Running both systems in parallel lengthens the calendar but reduces cutover risk. Ask for a written plan with phases and milestones before work starts.
What work does a privacyIDEA migration need from our team?
Your team supplies the knowledge of your environment, and the work falls into several areas. Network and security staff must inventory RADIUS clients, VPNs, Linux PAM hosts, Windows logon systems and web applications that use SecurID today. Identity staff must confirm where users live and how they resolve, since privacyIDEA reads users through LDAP (including Active Directory), SQL, SCIM, HTTP or flat file resolvers. Application owners must approve changes to login flows and test them. Service desk staff need enrollment procedures for new authenticators, and change control must cover cutover windows. Ask your implementation partner to document which of these tasks it performs and which remain with your staff.
Can our staff run privacyIDEA without outside help?
Yes, a capable team can run privacyIDEA alone, but the decision depends on skills you already have. privacyIDEA's installation documentation covers installation with pip and on Ubuntu and CentOS or RHEL-family systems, so Linux administration skills are the baseline. Your staff also need to operate a RADIUS and authentication service, manage user resolvers, handle token lifecycle and patch the platform on a schedule. Consider whether you have on-call coverage for an authentication outage, since MFA failures block logins. Many organizations keep internal ownership and buy specific help, such as the initial build or hardening. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure under fixed-scope agreements, and offers ongoing support as retainers.
How do upgrades and support differ between privacyIDEA community and Enterprise Edition?
The community edition is free software under AGPLv3, and its upgrades are published on the project's release page, where the latest version supplied is v3.14, published on October 7, 2026. Your team applies those releases, tests them and schedules downtime. The Enterprise Edition is available from NetKnights, and the project states that only one company is currently involved in its development. Ask NetKnights, in writing, what the Enterprise Edition includes, what response times it commits to and how it handles security fixes. Whatever edition you choose, define who tests upgrades, who approves them and how long you keep the prior version for rollback. Upgrade and monitoring work can be placed under a DeployOpen retainer.
Can we reuse our existing RSA SecurID hardware tokens in privacyIDEA?
Usually not directly, so plan to issue new tokens. privacyIDEA can import hardware token seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats, and it can import GPG-encrypted seed files. Seed files for SecurID are not among the supported formats, so exporting seeds from Authentication Manager into privacyIDEA is not a supported path in the sources reviewed. Confirm this with RSA and privacyIDEA for your token generation before you rely on it. If your current tokens are OATH-compatible, check the OATH CSV import route with your vendor. Otherwise, budget for new authenticators such as TOTP apps, FIDO2 keys, or the privacyIDEA Authenticator app, since push notifications need that app.
Which privacyIDEA token types can replace SecurID for our users?
privacyIDEA covers a wider set of token types than a SecurID-only deployment, but you must choose which types fit each user group. The platform supports FIDO2 and WebAuthn passkeys and hardware keys, PIV and x509 smartcards, push, TOTP and HOTP, SMS, email, SSH keys and registration codes. Users of standard TOTP and HOTP can keep apps such as Google Authenticator, while push needs the privacyIDEA Authenticator app. Map each user group, such as administrators, remote staff and service accounts, to a token type and a policy. Ask your team to confirm which combinations meet your internal assurance requirements, and do not assume a token type satisfies a control until your assessor agrees.
Who runs each option day to day
Running RSA Authentication Manager and running privacyIDEA put different work on your team. An Authentication Manager estate is typically administered through RSA's console, with its own upgrade paths and the agents installed on the systems that authenticate against it, so the core skills are RSA administration and agent management on Windows and Unix hosts. privacyIDEA runs as a Python application on Linux and can be installed with pip or on Ubuntu and CentOS or RHEL-family systems, as its installation documentation describes. Your team will need Linux administration, web server and database operations, and enough Python to read logs and troubleshoot. Inventory those skills before you choose.
Patching and backup move to your side in either case, but the work differs. Ask RSA which parts of your Authentication Manager deployment it patches or supports under your contract, including any appliance hardware. With privacyIDEA, your team owns operating system patches, Python dependency updates, release upgrades and the database that holds token and policy data. Your backup plan must cover that database, the configuration files and any key material used to protect token data, and you should test a restore on a separate host before go-live. Write down who restores the service out of hours, because no one else will do it unless you buy that service.
Support is where the two models differ most. RSA sells a support contract, and you should read its terms for covered products, response commitments and end-of-support dates. privacyIDEA is licensed under AGPLv3, so you can run it with community resources, or buy the privacyIDEA Enterprise Edition from NetKnights for commercial support. privacyIDEA.org states that the project has no single ruling company, although only one company is currently involved in it. Ask NetKnights and any other provider how they would keep your deployment supported if that changed, and request response times, escalation paths and upgrade commitments in writing before you compare the two.
Risks to check before committing
Replacing SecurID touches more than the token seeds. The risks below sit in the agents, RADIUS clients, upgrade calendar, team capacity and recovery design that surround Authentication Manager, and each one can delay or change the migration if it is left unchecked.
Agent dependencies on older servers
Authentication Manager agents are installed on Windows servers and web servers, and each agent version has its own support matrix. Before choosing privacyIDEA, list every host that runs an agent, its operating system and web server version, and whether the protected application can call privacyIDEA's PAM module, Windows credential provider, or REST API instead. Where no supported integration exists for a host, plan the replacement or a bridge for that host separately. Confirm each component against the privacyIDEA documentation and your own test systems, since integration coverage differs by platform.
RADIUS client compatibility
VPNs, firewalls and other network devices often point at Authentication Manager as a RADIUS server with a shared secret and a fixed access-challenge flow. privacyIDEA integrates with VPNs such as OpenVPN, Fortinet and Palo Alto through RADIUS, but each device's challenge handling, attribute expectations and user naming must be tested. Inventory every RADIUS client, record its challenge mode and how it sends the user name, and run one pilot per vendor before repointing production traffic.
Upgrade timing versus migration timing
Authentication Manager 8.7 SP2 leaves primary support in January 2027, which sets a hard date for the current estate. Map the upgrade path to 8.8, including its new operating system and TLS changes, against the time needed to issue tokens, enroll users and move every integration to privacyIDEA. If the migration will not finish before that date, decide whether to upgrade first, accept an unsupported period, or run both systems for longer. Confirm the support dates directly with RSA.
Staffing for an open-source MFA platform
With privacyIDEA, the operator owns the server, database, upgrades, token lifecycle and the integration maintenance that RSA handled under its support contract. Name who will patch the Linux hosts, watch the authentication logs, rotate the API credentials and answer help desk calls about enrollment. Decide whether internal staff, a support contract from NetKnights for the Enterprise Edition, or a DeployOpen retainer will cover each role, and ask any vendor to state the response commitments in writing.
Failover and disaster recovery testing
An MFA service that fails closed can lock out administrators and remote users during an outage, so the recovery design needs testing rather than assumption. Test a loss of the primary privacyIDEA node, a database restore, and the rebuild of a server from backup, and confirm that RADIUS and agent clients fail over as expected. Record how long each test takes and who performs it, then compare the results with the recovery targets your organization already sets for SecurID.
How DeployOpen helps evaluate, implement or migrate privacyIDEA
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For RSA SecurID vs privacyIDEA, we start with the token types, RADIUS clients and user stores you actually run, then build and hand over a privacyIDEA deployment that you control.
How we scope
- Inventory current SecurID token types, RADIUS clients, agents and the user sources they depend on.
- Agree token migration, enrollment and coexistence periods in a written, fixed-scope document before work starts.
- Confirm with your vendor, auditor or internal teams which features and licensing terms your environment requires.
How we build
- Install privacyIDEA on your chosen platform, connect LDAP or Active Directory resolvers, and configure policies.
- Repoint RADIUS clients, PAM and identity provider integrations in a staged order, with rollback steps for each.
- Test FIDO2, push, TOTP and hardware token enrollment, and document each result against the agreed scope.
How we hand over
- Deliver configuration, runbooks, backup and restore procedures, and an enrollment guide for help desk staff.
- Provide evidence of configuration and testing for your internal reviews or your external auditor to assess.
- Train administrators on operations, token lifecycle tasks and upgrade steps for the privacyIDEA release you run.
How we support
- Offer ongoing support, upgrades and continuous testing for privacyIDEA through a retainer agreed in writing.
- Plan upgrades against each privacyIDEA release, starting with a test environment that mirrors production.
- Review access policies and token inventories on a schedule you agree, and report changes in writing.
