Why RSA Authentication Manager 8.7 SP2 end of primary support forces a decision
Your choice is between the 8.8 upgrade of RSA Authentication Manager and replacing SecurID with self-hosted privacyIDEA. Authentication Manager 8.7 SP2 leaves primary support in January 2027, so the decision needs to be made, and budgeted, well before that date. Staying on RSA means moving to 8.8, which brings a new operating system, deprecated agents and TLS changes that your estate must absorb. Moving to privacyIDEA means replacing the authentication path itself. Neither option fits every organization, and the right answer depends on four things: the token types your users carry, the RADIUS and agent integrations that depend on the server, the user stores it reads from, and the operating constraints your team must work within.
Start with the token inventory. Count hardware fobs, software tokens and any use of push or certificate-based login, and record which users depend on each. privacyIDEA supports FIDO2 and WebAuthn, PIV and x509 smartcards, push, TOTP and HOTP, SMS and email, but its import formats do not include SecurID seeds, so fobs you keep will not carry over and any move means issuing new tokens. Next, list every RADIUS client, VPN, Windows logon, Linux PAM host and web application that calls Authentication Manager, along with the agent versions they run. Each entry shows whether it can be repointed or must wait for an upgraded agent. Confirm the 8.8 agent and TLS requirements with RSA in writing before you rely on them.
Then check the user stores and operating limits. Identify where accounts live today, whether in Active Directory, LDAP or a database, and confirm that privacyIDEA's LDAP and SQL resolvers can read them without changing the directory. Record your change windows, your Linux and Windows platform standards, and whether your team has the skills to run a self-hosted MFA service with its own backups and patching. Ask RSA for the 8.8 end-of-life and support dates for your exact version, and ask privacyIDEA's maintainers or NetKnights, which offers an Enterprise Edition, what support terms apply. Then pilot the option you favor with a small user group before committing to a full cutover.
What the upgrade and replacement paths must satisfy
Whether you upgrade to 8.8 or move to privacyIDEA, the same five areas decide the outcome: the platform underneath, the agents and clients that call it, the transport security they negotiate, the tokens your users already carry, and the directories that supply identities. Confirm each one against RSA documentation for your exact version before you commit budget or dates.
New operating system on 8.8
Authentication Manager 8.8 moves the appliance to a new operating system base, so an in-place upgrade is not a simple patch. Check which operating system build your current hardware or virtual appliance supports, whether your hypervisor and backup tools still work with it, and whether the upgrade path requires a fresh install instead. Ask RSA for the supported platform matrix and the documented upgrade sequence for your starting version.
Deprecated agents and integrations
Some agents and integration components that your web servers, VPN gateways or Windows hosts depend on may be deprecated or removed in 8.8. Inventory every system that calls Authentication Manager, including RADIUS clients and agent-based integrations, and record the agent version on each. Confirm with RSA which agent versions are supported on 8.8 and whether any replacement requires a change to the host or the client configuration.
TLS and protocol changes
Newer releases tighten the TLS versions, cipher suites and certificate requirements that connecting clients may use. Clients or load balancers that still negotiate older settings can fail after the upgrade, often without an obvious error. Test each connecting system against the 8.8 TLS requirements in a non-production environment, and confirm the certificate chain and key lengths that RSA documents for your version.
Token and seed continuity
Existing hardware and software tokens hold seeds that are bound to the current Authentication Manager database. Confirm whether 8.8 keeps every token assignment and seed without re-issuing, and whether your tokens are in a format the upgrade supports. If you plan to move to privacyIDEA, note that SecurID seeds are not among its import formats, so every user needs new credentials. Ask RSA for the token types in use and the procedure for each.
User store connectivity
Authentication Manager reads identities from an LDAP or Active Directory source. After an upgrade or a move, the connection settings, bind account, certificate trust and attribute mappings must still resolve the same users. Document the current directory connection, test a bind with a service account, and confirm with RSA how 8.8 handles directory sources and whether any setting must be re-entered. The same mapping work applies to privacyIDEA, which reads LDAP and Active Directory through its user ID resolvers.
What the 8.8 upgrade changes and what it leaves in place
The 8.8 upgrade keeps SecurID in place, so the first question is how much of your environment it touches. At a high level, the release moves Authentication Manager to a new operating system, retires some agent versions and changes how TLS is negotiated between the server and its clients. Each of these is a point where something that works today can stop working after cutover. Do not size this from a summary. Ask RSA for the 8.8 release notes and the list of deprecated agents, and confirm the exact operating system versions, minimum TLS protocol versions and cipher changes against your own estate. Record which agents and integrations sit on a deprecated version, because those items need a dedicated change window.
What the upgrade leaves in place is the SecurID model itself. Users keep their existing tokens and seeds, the authentication flow continues, and the licensing model carries forward, so the upgrade does not by itself require a token rollout. That continuity is the main argument for upgrading, and it also means the upgrade does not change the architecture you would be choosing to keep. Confirm with RSA that your current license entitlements, token counts and support terms transfer to 8.8 without a new purchase, and whether any hardware token generation is affected. Get those answers in writing before you schedule work, because commercial terms usually set the timeline more tightly than the technical steps do.
The step that protects you most is testing RADIUS clients and agents against a non-production 8.8 instance before cutover. Build an inventory that lists each RADIUS client (VPN concentrators, firewalls and remote access gateways), each agent on servers and workstations, and each web or application integration, with its version and the protocol settings it uses. Run live authentication scenarios for each group: a new token, a resynchronization, an emergency or offline case, and a failed attempt. Confirm the TLS settings each client negotiates, since a client that cannot complete the handshake often fails for some users first and without an obvious error. Keep the 8.7 SP2 system running and documented as a rollback path until the last client has passed.
Upgrade 8.8, privacyIDEA or Keycloak with privacyIDEA: how each path meets the requirements
This table compares three paths against the requirements that usually decide an end-of-support choice: staying on RSA with the 8.8 upgrade, self-hosted privacyIDEA, and Keycloak with privacyIDEA as the MFA layer. Read each gap as an item to test in a pilot before committing. The main takeaway is that the 8.8 path keeps your current tokens and agents, while both open-source paths require reissuing SecurID tokens and replacing agents.
| Requirement | Upgrade to 8.8 | privacyIDEA | Keycloak with privacyIDEA |
|---|---|---|---|
| Token types | Existing SecurID token types continue; confirm FIDO2 and push support with RSA for 8.8 | FIDO2, WebAuthn, push, TOTP, HOTP, PIV, SMS, email and SSH keys | Same token types, reached through the Keycloak plugin for browser logins |
| Existing hardware seeds | Confirm with RSA how current token records carry into 8.8 before planning | Gap: SecurID seeds are not an import format, so tokens must be reissued | Gap: same as privacyIDEA, since the plugin does not change seed import |
| RADIUS clients | Confirm client compatibility with the 8.8 release notes before upgrading | RADIUS for VPNs such as OpenVPN, Fortinet and Palo Alto; each client is repointed | RADIUS served by privacyIDEA; Keycloak covers browser SSO applications |
| Windows and server agents | Confirm agent versions and deprecated agents against the 8.8 compatibility list | Gap: Windows credential provider and PAM module replace SecurID agents and need testing | Windows logon uses the privacyIDEA credential provider; Keycloak adds SAML and OIDC apps |
| User stores | Confirm supported identity sources for your 8.8 deployment | LDAP and Active Directory, SQL, SCIM, HTTP and flat file resolvers | Built-in LDAP and Active Directory federation, plus privacyIDEA resolvers |
| Operating system and TLS | New operating system and TLS changes require a test upgrade in your environment | Installs with pip or on Ubuntu and RHEL-family systems; your team sets TLS | Two components to patch and configure, Keycloak and privacyIDEA |
| Licensing | Commercial subscription and support contract with RSA | AGPLv3 open source; optional NetKnights Enterprise Edition support | Keycloak under Apache License 2.0; privacyIDEA under AGPLv3 |
| Support model | Vendor support under your RSA contract; confirm the 8.8 support timeline | Community project; production support from NetKnights or another provider | Community project; choose a commercial support provider for production |
| Data location | Runs in your environment; confirm which data, if any, leaves it | Keeps user data inside your own infrastructure | Keeps user and token data inside your own infrastructure |
Which path fits which environment
Organizations with a large installed base of hardware tokens, fixed RADIUS clients and little appetite for changing VPN or network gear often find the 8.8 upgrade the shorter route to staying supported. The upgrade keeps existing token behavior and RADIUS configuration in place, though it brings a new operating system and changed TLS and agent requirements that must be tested first. Replacement is more likely to make sense when the reader expects to reissue tokens anyway.
- Token inventory: Confirm how many hardware tokens are in use, their types and whether any are near end of life, since privacyIDEA does not import SecurID seeds and reissuing tokens is a cost to plan for.
- RADIUS client list: List every VPN, firewall and appliance that sends RADIUS requests to Authentication Manager, along with the shared secrets and timeout settings each one uses.
- Agent dependencies: Identify Windows and web server agents, and check which of them are deprecated in 8.8 and whether vendor support covers your operating system.
- Operating system and TLS: Ask RSA which operating system the 8.8 appliance or software requires and which TLS versions and cipher suites changed, then test clients against them.
- Parallel running: Confirm whether a second RADIUS server can run during any cutover so that clients can be repointed in stages.
Before choosing, confirm the upgrade path and its support dates directly with RSA, since those dates are the trigger for this decision.
Organizations that want phishing-resistant sign-in, passkeys or push approval for staff are asking for capabilities that define the token strategy rather than a patch to an existing one. privacyIDEA supports FIDO2 and WebAuthn passkeys and hardware keys, along with push, which makes it a plausible destination for this group. The reader should check that the target applications accept the methods they plan to use and that users can enroll without help-desk bottlenecks.
- Method mapping: List the applications and access paths that need passkeys, push or hardware keys, and confirm each one can be reached through privacyIDEA's supported integrations.
- Authenticator apps: Note that standard TOTP and HOTP users can keep apps such as Google Authenticator, while push notifications require the privacyIDEA Authenticator app, so plan distribution to managed devices.
- Enrollment design: Decide who enrolls passkeys and push devices, and whether enrollment uses registration codes or a self-service flow.
- Phishing resistance: Confirm which methods your policy treats as phishing resistant, and whether SMS or email fallback is still required.
- Coexistence period: Plan how long SecurID and new methods run side by side, because users will hold both during enrollment.
Before committing, test the chosen methods with a pilot group on the applications that matter most.
Organizations that must keep user identities in Active Directory or LDAP, whether for policy, audit or application reasons, need to know how each option reads and authenticates those users. privacyIDEA reads users through LDAP resolvers, which work with any LDAP service including Active Directory, so directory-bound users need not be migrated into a new store. The upgrade path also keeps the existing directory link, which may matter if many applications depend on it.
- Directory ownership: Confirm who owns the directory schema and whether the security team can add LDAP bind accounts with read-only rights.
- Resolver behavior: Test how privacyIDEA maps attributes, group membership and disabled accounts from your directory before users are enrolled.
- Password handling: Decide whether MFA sits alongside the directory password or whether the directory password is replaced, since that changes what users and help desks must support.
- Authentication chain: Document which systems authenticate against Authentication Manager today and which read identities from the directory, so nothing is left behind.
- Directory change plans: Check whether a planned directory migration or consolidation would change the resolver configuration.
Before choosing, map every system that depends on the directory and the LDAP connection to find the ones that need testing first.
Many organizations fall between these profiles, with some hardware tokens, a few passkey pilots and several directory-bound applications. In that case the decision usually comes down to which group carries the most users and the most critical access, and whether a staged approach lets the reader keep the upgrade as a bridge while testing a replacement. Avoid choosing a path based on the support date alone, because the cost of reissuing tokens and rebuilding clients can outweigh the upgrade cost.
- Inventory first: Build one inventory of users, token types, RADIUS clients, agents and directory dependencies before comparing paths.
- Priority groups: Rank user groups by business criticality and by the effort needed to move them.
- Bridge option: Ask RSA whether the 8.8 upgrade can serve as an interim step while a replacement is tested.
- Support boundaries: Confirm how commercial support and open-source community or paid support would each handle a fault during coexistence.
- Evidence trail: Keep records of decisions, test results and access changes, since auditors will ask how the change was controlled.
Before choosing, get written answers from RSA on upgrade support dates and from any replacement candidate on the capabilities your inventory actually requires.
How to inventory and test before choosing
This sequence gives you a factual picture of how SecurID is used today, a tested 8.8 upgrade path and a small privacyIDEA pilot, so the upgrade-or-replace decision rests on your own environment rather than on assumptions. Each step produces a record that the next step depends on.
Export the current token inventory
Your security or identity administrator exports the list of hardware tokens, software tokens and their assignments from Authentication Manager, using the administration console reports or your own export procedure. Record token type, serial number, assigned user, last used date and whether the seed record is held by RSA only. Confirm the export format with RSA support before relying on it. The step is complete when every active token has one row in a spreadsheet that someone other than the author has reviewed.
Catalog seed sources and token formats
Identify where each token's seed material came from, such as factory-issued hardware files, software token provisioning or an earlier import, and whether those seeds can be obtained in a usable form. Ask RSA in writing which seed export options apply to your licensing and tokens. Note any tokens that are not OATH-compatible, because privacyIDEA's supported import formats are a narrower set than the seed sources you may have. The step is complete when each token group is labeled as importable, reissue required or unknown.
List RADIUS clients and agents
Build a register of every system that sends authentication requests to Authentication Manager: VPN concentrators, network devices, remote access gateways, Windows and Linux logon paths, and web servers with SecurID agents. For each, record the vendor, firmware or agent version, the protocol used and the owner who can change its configuration. Flag any agent that depends on a deprecated component in the 8.8 release notes. The step is complete when the register matches what your network and security teams confirm from their own configuration records.
Map user stores and authentication sources
Document where user identities live today, including Active Directory domains, LDAP directories, SQL tables and any manual user lists, and which of them Authentication Manager reads. Identify attributes that drive token assignment and group membership. Check whether privacyIDEA's user ID resolvers (flat file, LDAP, SQL, SCIM and HTTP) can read each source with the same attributes. The step is complete when each user population maps to one source of truth and an owner for each.
Test the 8.8 upgrade in a lab
Build a lab copy of Authentication Manager, install the 8.8 release on the target operating system your vendor specifies, and restore a recent configuration backup into it. Run test logons through each RADIUS client and agent from the register, including failure and lockout cases. Check the TLS settings and any agent that your register flagged as deprecated. Confirm the lab's support position with RSA before you treat the result as a supported path. The step is complete when every client in the register has a documented pass or a named blocking issue.
Install a privacyIDEA pilot
Install privacyIDEA in a test environment using the method your platform team supports, such as pip or the Ubuntu or RHEL-family packages described in the installation documentation. Confirm the target operating system version and database requirements in that documentation before you start, since they change between releases. Connect a test user resolver and configure one RADIUS or web integration. The step is complete when a test user can authenticate through the pilot path and the result is logged.
Pilot with a subset of users
Enroll a small, named group of volunteers in privacyIDEA alongside their existing SecurID tokens and run both for a defined period you agree in advance with the business owners. Measure enrollment problems, help desk tickets, failed logons per client and any token types that users cannot register. Confirm whether standard TOTP apps are acceptable to your users, and whether push requires the privacyIDEA Authenticator app. The step is complete when you have a written go or no-go decision for each client group, with the upgrade path as the fallback.
What happens to existing SecurID tokens
Plan on reissuing most hardware tokens if you move to privacyIDEA. privacyIDEA can import seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats through its Token import workflow, and the OATH CSV format covers HOTP, TOTP, OCRA and TAN tokens. SecurID seed records are not among those supported formats, so a file exported from Authentication Manager cannot be assumed to load. Before you commit to a timeline, have someone test a single token import in a non-production privacyIDEA instance, using a seed file exported from your own deployment.
Start by asking RSA, through your account team or support, which export options your specific Authentication Manager 8.7 SP2 deployment and licensing hold. Ask whether seed or token records can be exported at all, in what format, and whether the export requires a particular role or a support engagement. Get the answer in writing. Also confirm which token types you actually hold, since software tokens, hardware fobs and any push-based authenticators follow different paths. Do not treat any converted file as a guarantee until the test import has succeeded and a sample of users has authenticated with it.
Enrollment of new authenticators is the operational work that follows. Decide which factors replace each SecurID token type, for example FIDO2 keys, push through the privacyIDEA Authenticator app, or TOTP for users who keep a standard app, and plan the user communication and help desk capacity around the cutover. Keep the existing system running until enrollment reaches the population you agreed on, and record which users remain on SecurID so that your RADIUS and agent cutover plan stays accurate.
Evidence to keep for the decision and the cutover
Whichever path you choose, the decision and the cutover will be examined later by an auditor, a regulator or your own risk committee. The cards below describe the records that let you show what you had, what you tested, what you changed and who could still sign in. Build them while the work happens, not after.
Token and agent inventory
List every SecurID token type in use, its serial, assigned user or device, and status, along with every RADIUS client, Windows and web agent, and the systems each one protects. Auditors use this to confirm that no authentication path exists outside the documented scope. Export it from Authentication Manager and reconcile it against your CMDB and firewall rules, because agents often outlive the applications they were installed for. Confirm which agent versions are deprecated under the 8.8 upgrade before you start.
Upgrade test results
Record the test plan, the test environment build, and the pass or fail result for each authentication flow, including token logins, emergency access, RADIUS requests, agent logins and TLS negotiation with each client. Note the operating system version under test and any TLS settings that changed. A tested, dated record shows the upgrade was verified before production, which is the main evidence for change management. Ask the vendor which release notes and compatibility matrices apply to your exact version.
RADIUS and agent configuration records
Keep copies of the RADIUS client definitions, shared secret ownership, agent configuration files and the TLS settings on each integrated system, taken before and after any change. Shared secrets should be stored in a managed vault with a named owner, not in a spreadsheet. These records show that each integration was configured as approved and that no client was left pointing at a retired server. Compare them with the inventory to find gaps.
Cutover change log
Maintain a timestamped log of each change: the request, the approver, the systems touched, the rollback plan, the cutover window and the verification steps completed. For a migration, add each token reissue batch and each cutover of an application to a new authenticator. Regulators look for proof that changes followed your change process and that you could roll back. Include any step where both systems ran in parallel, and when the old path was disabled.
Access reviews during the transition
Run and document access reviews for who can administer Authentication Manager or the replacement, who holds an active token, and who can bypass MFA. Repeat the review after each batch of enrollments and at the point the legacy system is shut down. Access reviews show that privileged access to the authentication system stayed controlled while the platform was in flux. Record reviewer, date, decisions and removals, and keep the signed output with the change log.
Questions buyers ask before choosing a path
What does it cost to upgrade to 8.8 or move to privacyIDEA?
The cost depends on which components change, not on a single line item, and RSA does not publish list prices, so the figures must come from your own quotes. For an upgrade, ask what is included in your current support entitlement, what the 8.8 move requires in new operating system and server work, and what happens to deprecated agents you still run. For privacyIDEA, the recurring pieces are server hosting, your staff time, and any optional NetKnights Enterprise Edition support. The one-time pieces are the migration project, new authenticators, and the cutover period when both systems run. Ask every bidder to split their quote by these components so you can compare them directly. The privacyIDEA GitHub releases page shows the open-source release cadence you would be planning around.
How long does a SecurID migration take?
The pace is set by how many users, tokens, RADIUS clients and agent-based systems you have, and by how many enrollment waves your support desk can absorb. Migration to privacyIDEA involves issuing new tokens, because SecurID seeds are not among privacyIDEA's import formats, so user enrollment is usually the longest task. Ask any implementation partner for a written timeline built from your inventory, with fixed milestones for pilot, each enrollment wave and decommissioning. Ask how the plan handles running both systems in parallel and what rollback looks like if a wave fails. Do not accept a duration that is not tied to a counted inventory.
What information do we need to give a partner before a quote?
A partner can only write a fixed-scope quote from an accurate inventory. Prepare a list of user populations and directories, including whether users sit in Active Directory or LDAP, since privacyIDEA reads users through LDAP and SQL resolvers. List every RADIUS client, VPN and appliance that authenticates against SecurID, and every Windows, Linux and web system that uses an agent or integration. Record the token types in use, the number of hardware tokens, and the seed files you hold. Include your current support and renewal dates, your change-control process, and your data residency and logging requirements. Written scope is what makes the quote comparable.
Can our own team run the migration without an outside partner?
Your team can do the work if it has people who already operate Linux servers, LDAP directories and RADIUS integrations, and if it has time that is not already committed to other projects. The privacyIDEA documentation covers installation with pip and on Ubuntu and CentOS or RHEL-family systems, so the platform itself is accessible to a capable engineering group. The harder parts are usually the RADIUS client repointing, Windows and web server agent replacement, security review, and user communication. Ask a partner to separate the work it would do from the work your staff would do, and to state what your team must own after handover, including upgrades and backups.
Is upgrading to 8.8 riskier than replacing SecurID?
Neither path is inherently safer, because each carries different risks. An upgrade keeps your token base and user experience but moves you onto a new operating system, retires deprecated agents and changes TLS behavior, so the risk sits in compatibility testing of every client you depend on. Replacement changes the token and authentication stack, so the risk sits in enrollment, user adoption and integration gaps. Ask for a compatibility matrix from whichever path you choose, and confirm the 8.8 operating system, agent and TLS details directly with RSA, since those specifics should come from the vendor documentation for your environment. Then compare the rollback options for each path in writing.
Which SecurID features does privacyIDEA not cover?
privacyIDEA covers a wide set of factors, including FIDO2 and WebAuthn, PIV and x509 smartcards, push, TOTP, HOTP, SMS, email and SSH keys, but a direct feature-for-feature match is not guaranteed. Review your current use of on-demand tokens, risk-based policies, specific agent behaviors and any vendor support commitments against the privacyIDEA documentation and release notes. Where a gap exists, ask whether a supported integration, a custom plugin or a process change closes it, and who would maintain that work after go-live.
Who supports the platform after the project ends?
Support for an open-source platform comes from your own operations team, the community and any commercial support contract you buy. privacyIDEA is licensed under AGPLv3, and privacyIDEA.org states that the Enterprise Edition is available from NetKnights, so commercial support is an optional add-on rather than a requirement. Ask a partner whether it offers an ongoing support retainer, what its upgrade and backup responsibilities would be after handover, and how it would test a new release before you deploy it. Those answers determine your long-term operating cost more than the initial build does.
How the cost of each path is built
On the upgrade path, the one-time costs are the 8.8 upgrade itself: planning, staff time, a test environment that matches production, and regression testing of every RADIUS client, agent and web integration against the new operating system and the TLS changes. Those tests are usually the largest unknown, so ask who performs them and whether the work is fixed in a written scope. The recurring costs sit in the RSA license and support terms. Confirm with RSA or your reseller the term length, renewal pricing and whether support coverage after January 2027 changes. RSA does not publish list prices, so the figures must come from your own agreement. Also confirm how many hardware tokens you hold, their replacement terms and whether any of them will need replacing during the new support window.
On the privacyIDEA path, the software license carries no fee because privacyIDEA is licensed under AGPLv3, so cost sits in infrastructure, labor and any support contract. Expect one-time work for servers in your own environment, installation through pip or the Ubuntu or RHEL-family packages, integration with your PAM, Windows, VPN and application endpoints, and migration of users and tokens. Recurring costs are the servers, patching, monitoring, backups and staff time to run the platform. Optional NetKnights Enterprise Edition support is a separate subscription and should be priced as a line item. Authenticator choices also carry cost: standard TOTP and HOTP apps may already be in use, while push requires the privacyIDEA Authenticator app, so check the terms of any app store or device program your users rely on.
The cost drivers on both paths are user count, the number of integrations that must be retested or rebuilt, the length of any parallel run, and how many tokens must be reissued. Ask every vendor or partner for an itemized quote that separates one-time work from annual charges, states the term and renewal escalator, and names what is excluded. For a detailed breakdown of each component and a worksheet structure, read the cost comparison page in this series. Because both paths require testing and a period where old and new systems run together, price that overlap explicitly rather than treating it as free.
How DeployOpen works on this
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For RSA Authentication Manager 8.7 SP2 end of primary support: upgrade or replace, we start by mapping the current SecurID estate, then compare the 8.8 upgrade path with a privacyIDEA deployment before any work is agreed.
How we scope
- We inventory SecurID tokens, RADIUS clients, agents and user stores before recommending upgrade or replacement.
- The written scope names which systems move, which stay, and the cutover dates the client has confirmed.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
- We ask RSA or the client's account team to confirm 8.8 requirements, agent support and licensing terms in writing.
How we build
- We stand up a privacyIDEA test environment in the client's infrastructure, using the documented pip or Linux package installation.
- We connect the existing user store through privacyIDEA's LDAP or SQL user ID resolvers and test authentication paths.
- We repoint RADIUS clients and test VPN and web logins against both systems in parallel.
- We run security testing on the new authentication path and document the configuration and evidence produced.
How we hand over
- The handover includes configuration documentation, runbooks, token enrollment procedures and rollback steps.
- We prepare control evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports.
- Backup and restore procedures are documented and tested for the new identity stack before cutover.
- Staff are trained on operating the platform so the client's team can run it after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers cover privacyIDEA version upgrades, such as moving between published releases, with changes tested first.
- We review the open-source release history and advisories with the client so upgrade decisions stay visible.
- Clients should confirm which support tier, whether community or NetKnights Enterprise Edition, fits their risk profile.
