Migrate from Cisco Duo to privacyIDEA

How to migrate from Cisco Duo to privacyIDEA without locking users out

Moving from Cisco Duo to privacyIDEA is an inventory, enrollment and integration project, and the effort and risk depend mainly on how many integrations sit behind Duo and how many hardware tokens are in circulation. Before the renewal date, the team should count every application, VPN, RADIUS client, Windows logon and Linux PAM stack that calls Duo, and list every user who holds a hardware token. Those two counts set the size of the work far more than the number of user accounts does. Internal platform and security teams usually own the project, and many bring in an implementation partner such as DeployOpen for the integration and enrollment waves, with the written scope agreed before work starts.

The real risk sits in enrollment, not in data. User records can be pulled from the Duo Admin API and matched to Active Directory or LDAP through privacyIDEA's user ID resolvers, so identities are rarely the hard part. The hard part is that each user must have a working second factor in privacyIDEA before Duo is switched off. Duo Mobile users will need to re-enroll, because their Duo device will not carry over. Hardware token seeds can be imported from OATH CSV, PSKC or Yubikey formats, but the team should confirm with the seed supplier which format and encryption they will receive, and should test a sample token end to end before the bulk import. A pilot group, a fallback path for users who lose a device, and a help desk script for re-enrollment reduce lockout risk more than any technical setting.

Plan the cutover as a dual-running period. Keep Duo active for the integrations you have not yet moved, and move one integration at a time, for example a single VPN gateway or one Linux PAM group, while privacyIDEA handles the same logins through its RADIUS or PAM integration. Confirm with the privacyIDEA project and your own test environment which installation method fits your platform, since the documentation covers pip installs and Ubuntu and CentOS or RHEL-family systems. Ask your partner for a written list of which Duo features each target integration replaces and which it does not, so that no login path is left without a second factor when Duo is retired. Keep the Duo export files and the token inventory under access control until the team has confirmed a clean rollback path.

Which Duo capabilities map to privacyIDEA and which need rework

This table maps the Duo capabilities a migration usually touches to privacyIDEA equivalents and marks each row as clean, needs rework or gap. Read it against your own Duo policy export and integration list, because the status depends on which factors and integrations you actually use. Risk-based and device trust features have no documented equivalent in the sources we reviewed, so confirm them in privacyIDEA's own documentation before you plan around them.

Duo capability	privacyIDEA equivalent	Status and what to check
Duo Push	Push through the privacyIDEA Authenticator app	Needs rework: users must enroll the privacyIDEA Authenticator app, not Duo Mobile
TOTP codes in Duo Mobile	TOTP tokens, including standard authenticator apps	Clean for standard TOTP: users of common TOTP apps can usually keep their app, but confirm seed import for each token type
Hardware tokens (OTP keys)	HOTP and TOTP hardware tokens imported from seed files	Needs rework: export seeds from Duo, then import in OATH CSV, PSKC or Yubikey formats
FIDO2 and security keys	FIDO2 and WebAuthn tokens	Clean if keys are registered in privacyIDEA: users must re-register, since Duo registrations do not transfer
RADIUS via Duo Authentication Proxy	RADIUS integration for VPNs and network devices	Needs rework: point devices at privacyIDEA RADIUS and test each VPN and firewall profile
Windows logon and RDP	Windows credential provider	Needs rework: confirm supported Windows versions and offline behavior before rollout
Linux SSH and local login	PAM module	Needs rework: roll out the PAM module across servers and test fallback access
SSO MFA for web applications	Keycloak plugin, AD FS, Shibboleth or REST API	Needs rework: map each application's SAML or OIDC flow to the chosen identity provider plugin
SMS and email codes	SMS and email tokens	Clean in principle: SMS delivery needs your own gateway and cost review
Risk-based authentication and device trust	No documented equivalent in the sources reviewed	Gap to confirm: check privacyIDEA's own documentation and plan compensating controls if it is missing

What data moves cleanly and what must be re-created

Most of the identity data you need can be carried into privacyIDEA without re-enrollment, but the second-factor enrollments are a different matter. User records stay in your directory. privacyIDEA reads users through its user ID resolvers, which include LDAP and Active Directory, SQL, SCIM, HTTP and flat file sources. Point a resolver at the directory that already feeds Duo, and the directory remains the source of truth for usernames, groups and attributes. What you do need to build is the Duo side of the inventory: export users, phones, hardware tokens and integrations through the Duo Admin API, then match each Duo username to the directory identifier privacyIDEA will use. Confirm which Duo plan and API permissions your account has before planning, and check the scope of the export against Duo's own export documentation, since access differs by edition.

Hardware tokens are the part that can move as data. privacyIDEA's Token import accepts hardware token seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats, and it can import GPG-encrypted seed files using its own GPG key. Before you import, obtain the seed files from your token vendor or from Duo under the terms of your contract, store them encrypted, and check that each token serial, seed, OTP length and time step lands correctly with a test login from a sample token. Seeds that cannot be exported from the vendor cannot be recovered from privacyIDEA, so treat that as a procurement question to settle before the Duo contract ends.

Duo Mobile enrollments are not seeds and must be re-enrolled. Push approvals and device trust are tied to the Duo app instance on each phone, and no export gives privacyIDEA a secret it can reuse. Plan a user-by-user enrollment window: standard TOTP and HOTP users can keep an existing authenticator app, while push users need the privacyIDEA Authenticator app. Keep Duo active in parallel until each group has enrolled, and give the help desk a documented fallback, such as a registration code or a temporary token, so no one is locked out. Document which users used Duo Mobile, which used hardware keys and which used SMS, because each path needs a different re-enrollment step.

Which integrations to rebuild in privacyIDEA

Duo rarely works alone. Each integration below depends on a different privacyIDEA component, so the migration plan needs one owner and one test case per integration. Treat each card as a separate work item with its own rollback path.

LDAP or AD resolver

privacyIDEA reads users from existing stores through user ID resolvers, and an LDAP resolver works with Active Directory. Map the directory attributes that Duo currently matches, such as the username and the mail or phone attribute used for enrollment, and confirm that every user Duo protects resolves to exactly one privacyIDEA user. Test bind credentials, search base and the service account's read rights in a staging copy before cutover. Confirm the exact resolver settings against the privacyIDEA documentation.

Hardware token import

Hardware token seeds exported from Duo must be converted into one of the formats privacyIDEA imports, such as OATH CSV, PSKC or Yubikey CSV, and loaded through the Token import function. Verify each imported token with a live OTP before retiring the Duo record, because a wrong seed or time step will look like a working token until the first login fails. Plan how seed files are stored and destroyed after import, and whether GPG-encrypted import fits your key management. Confirm the format details in the privacyIDEA documentation.

RADIUS for VPNs and network devices

Duo Authentication Proxy typically sits between VPNs, firewalls and network devices and Duo's cloud. privacyIDEA takes over that role as a RADIUS server on your own network, so each device needs its shared secret, server address and timeout reconfigured. Test one device at a time, and confirm how each VPN handles challenge-response prompts for push or OTP before you change the default factor. Confirm the RADIUS settings against the privacyIDEA documentation for your device vendor.

Windows credential provider

The privacyIDEA Windows credential provider adds a second factor to logon and RDP sessions on Windows machines. Inventory which logons Duo protects today, including console, RDP and offline or cached logons, because each one behaves differently after the switch. Pilot on a small set of workstations, and decide how users recover access if the MFA server is unreachable. Confirm supported Windows versions and configuration against the privacyIDEA documentation.

Linux PAM module

The privacyIDEA PAM module replaces Duo Unix for SSH and local logins on Linux. Each server needs the module, the PAM stack order and the SSH daemon settings reviewed, and a break-glass local account kept in case the MFA service fails. Roll the change across a fleet in groups, starting with non-production hosts, and record which factor each group uses. Confirm the PAM configuration keys against the privacyIDEA documentation before rollout.

SSO MFA through Keycloak or AD FS

Where Duo protects web SSO, privacyIDEA plugs into Keycloak or AD FS as an identity provider integration, so the second factor runs inside the login flow for those applications. Map each relying party that Duo currently covers and confirm that the chosen plugin supports the factors your users already enroll. Test the full login path, including password reset and account lockout, before moving production users. Confirm plugin versions and settings against the privacyIDEA documentation.

The migration sequence from inventory to Duo decommission

The sequence moves Duo users, devices and hardware tokens into privacyIDEA in controlled stages, so each integration is proven before the next one changes. It ends with Duo switched off only after every login path has been verified on privacyIDEA.

Export the Duo inventory
The identity or security team pulls users, phones, hardware tokens, integrations and recent authentication logs from the Duo Admin API, using an Admin API application with read permissions. Confirm first which plan includes Admin API access and how the rate limits apply to your account. The output is a versioned inventory file that lists each user, enrolled factor, device type, token serial and the application or proxy each login uses. The step is done when the record counts match what the Duo admin console shows.
Map identities to directory sources
Work with the directory owner to confirm where each Duo user is defined, usually Active Directory or LDAP. Configure privacyIDEA user ID resolvers against those stores so usernames in the inventory resolve to the same accounts that log in today. Flag accounts that exist in Duo but not in the directory, and accounts with duplicate or changed usernames. The output is a reconciliation sheet with one row per user and a resolver status. The step is done when every active Duo user resolves in privacyIDEA or has a recorded decision to exclude them.
Build privacyIDEA and run a pilot group
Install privacyIDEA in your environment, following the installation guide for your operating system, and configure the policies for the factors you plan to offer. Choose a small pilot group that includes a help desk member and users from each main application. Enroll pilot users, with standard TOTP or the privacyIDEA Authenticator app for push, and record which login paths they used. The output is a pilot sign-off list that names each user, the flows tested and the open issues. The step is done when the pilot group has completed logins through every flow in scope and the sponsor signs the list.
Import hardware tokens and verify seeds
Export hardware token seeds from the vendor source in a format privacyIDEA supports, such as OATH CSV, PSKC or Yubikey CSV. Import the files through the Token import function, using GPG encryption if the seed file requires it, and keep the source files in controlled storage. Test a sample of imported tokens against real logins before importing the rest. The output is an import report with serials assigned and a list of tokens that failed validation. The step is done when sampled tokens authenticate and the failed list has an owner for each entry.
Run the parallel period by flow
Keep Duo active while privacyIDEA serves a defined set of flows, for example one VPN group or one internal web application. Give users written guidance on which login uses which system during this period, and track help desk tickets by flow. Review the authentication logs from both systems at a set interval you agree in advance. The output is a parallel-run log that records each flow, the switch date and any rollback decisions. The step is done when every flow in scope has run on privacyIDEA without unresolved incidents.
Cut over each integration in turn
Move one integration at a time: RADIUS clients such as VPNs and network devices, the Windows credential provider, the Linux PAM module, and SSO applications that use Keycloak or another identity provider plugin. Replace the Duo Authentication Proxy with privacyIDEA's RADIUS integration for each path, and check the shared secrets and timeouts for each client. Write a cutover runbook per integration that lists the change steps, the test logins, the rollback steps and the named approver. The output is a signed runbook for each integration and a record of the change window. The step is done when each integration logs in successfully from its production client.
Decommission Duo after verification
Before turning off Duo, confirm that no integration still sends authentication requests to Duo, using the Duo logs and the proxy configuration. Export a final set of Duo logs and the inventory snapshot for your records and retention policy, and check your contract terms for data return or deletion. Remove the Duo applications, proxy servers and enrollments in the agreed order, and document the date for each removal. The output is a decommission record and an archive of the Duo exports. The step is done when Duo reports no active traffic and the archive has been checked by the data owner.

What drives migration cost and duration

This table lists the cost components of a Duo to privacyIDEA move and the drivers that change the effort in each. Read it as a checklist for your own inventory: the drivers that apply to your estate will set most of the work, and the right-hand column names what to reduce them. No price or duration is stated because none is supplied for this comparison, so ask for each figure in writing.

Cost component or driver	Why it changes cost or effort	How to keep it down
Internal staff time	Your identity, network and help desk staff run the inventory, test flows, cut over RADIUS and Windows or Linux logons, and support users. This is usually the largest share and recurs during each phase.	Limit the pilot to a few groups, reuse existing change windows, and assign one owner for token and user data.
Implementation partner scope	A fixed-scope partner quote follows from the written list of integrations, token imports and endpoints. Unclear scope drives change requests.	Give the partner your Duo Admin API export, integration list and endpoint count before asking for a quote, and agree deliverables in writing.
Servers and high availability	privacyIDEA runs on your own servers, so you pay for hardware or virtual machines, a database, load balancing and a second node for failover. These are one-time setup costs plus ongoing operation.	Confirm the supported install path for your OS (pip or the Ubuntu, CentOS or RHEL-family guides in the installation documentation) and size nodes to peak login volume.
Optional NetKnights Enterprise Edition subscription	The privacyIDEA Enterprise Edition is available from NetKnights. It is recurring and optional, and the scope of what it includes must be confirmed with the vendor.	Ask NetKnights which support, features and terms apply to your deployment before deciding whether the subscription is needed.
SMS and messaging costs	If users keep SMS codes, every message carries a per-message cost from your carrier or gateway. This recurs and grows with headcount and roaming users.	Move users to TOTP, push through the privacyIDEA Authenticator app or FIDO2 where policy allows, and keep SMS as a fallback only.
Hardware tokens	Tokens you already hold may be importable, but replacements, new purchases and returns are one-time costs. Seed import formats (OATH CSV, PSKC, Yubikey CSV) must be matched to what the token vendor provides.	Count tokens in the Duo inventory first, confirm the seed format with the vendor, and import only tokens that stay in service.
Number of users	Each user needs enrollment, a tested second factor and a help desk path. Effort scales with headcount and with the number of users who must change apps.	Migrate by group in waves, and keep standard TOTP apps working for users who do not need push.
Number of RADIUS and VPN integrations	Each RADIUS client, VPN concentrator or network device must be pointed at privacyIDEA and tested, replacing the Duo Authentication Proxy. Shared secrets and timeouts differ by device.	List every device that sends RADIUS or LDAP traffic to the Duo proxy and test one of each vendor family before cutover.
Windows and Linux endpoints	Windows logon or RDP and Linux SSH or PAM changes touch each machine or fleet. Rollout is slower where the MFA server is reachable only from some networks, and test accounts are needed for each platform.	Group endpoints by platform, script PAM and credential provider changes, and keep a break-glass local path during rollout.
Directory quality	privacyIDEA resolves users through LDAP or Active Directory and other resolvers. Duplicate accounts, stale users or inconsistent attributes add cleanup work before import.	Clean the directory and confirm the attribute used as the login name before configuring resolvers.
Enrollment method	Self-enrollment with guided steps needs less help desk time than in-person or ticket-based enrollment. Re-enrolling Duo Mobile users requires a new app and a fresh device binding.	Use a documented self-enrollment flow with a short window, publish the steps, and schedule enrollment outside peak help desk hours.

How the migration changes by starting point

When Duo protects logins to web applications through an SSO provider, the work centers on the identity layer that already issues those logins. Teams usually either keep their SSO provider and attach a second factor to it, or move the SSO function itself. The first step is to confirm which application the Duo integration sits in front of and whether the SSO provider can call an external MFA service, because that decides between pairing Keycloak with privacyIDEA and moving to a privacyIDEA plugin on an existing provider.

Map every Duo integration: List each application that uses Duo as its second factor, along with the SSO provider it signs in through.
Choose the MFA component: Keycloak has built-in OTP and WebAuthn, while privacyIDEA adds push, smartcards and hardware token support through its Keycloak plugin.
Plan enrollment per user group: Users with Duo Mobile must re-enroll, so schedule waves by department and keep a fallback method for each.
Keep the RADIUS path separate: VPN and network logins that Duo protects through the proxy need their own cutover, even when the web flow moves first.
Test the SSO flow end to end: Confirm session lifetimes, step-up rules and logout behavior in a staging realm before any production login changes.

Before the cutover, confirm with the SSO vendor or the Keycloak and privacyIDEA documentation which factor types the chosen integration supports in your version.

What usually goes wrong and how to prevent it

Most failed Duo-to-privacyIDEA cutovers fail on people, data formats and network dependencies rather than on the software itself. The cards below group the risks that tend to surface during enrollment, token import, RADIUS cutover and the contract end date, with a prevention step for each.

Users locked out during re-enrollment

Duo Mobile push and enrollment does not transfer to privacyIDEA, so every user must register a new factor before Duo is switched off. If the cutover date arrives before enrollment is complete, people cannot sign in to VPNs, SSH or Windows. Prevent it by running privacyIDEA in parallel and keeping Duo active until every user has enrolled and tested a login. Track enrollment per group in a spreadsheet exported from the Duo Admin API, and set a help desk procedure for identity verification before reset.

Hardware token seeds imported incorrectly

Hardware tokens rely on a seed, and a wrong format, serial or time step produces codes that never validate. The OATH CSV import covers HOTP, TOTP, OCRA and TAN lines, so a TOTP token with a 30-second step loaded as a different step will silently fail. Prevent it by importing a single test token first and checking one code against the physical device before loading the batch. Confirm the seed file format against the import documentation for each token vendor.

Duo Mobile users left without a second factor

Users who relied on Duo Mobile push may have no working factor on the day Duo is disabled, especially if they never installed a standard TOTP app. Push notifications require the privacyIDEA Authenticator app, while standard TOTP and HOTP can use apps such as Google Authenticator. Prevent it by assigning every Duo Mobile user a second enrolled factor, such as TOTP or a hardware key, before any policy change. Confirm which factors your policies will enforce for each group.

RADIUS shared secrets and timeouts mismatched

VPNs and network devices that point at the Duo Authentication Proxy must be repointed to privacyIDEA's RADIUS endpoint with a matching shared secret, port and timeout. A mismatched secret typically causes every authentication to fail, and a timeout shorter than the MFA response time causes intermittent failures that are hard to diagnose. Prevent it by documenting each device's RADIUS settings and testing one device at a time in a non-production window. Record the current Duo proxy timeout values before changing anything, and confirm how each VPN handles retries.

Windows or SSH logins blocked when MFA is down

Windows logon and SSH sessions that depend on an MFA server stop working if that server is unreachable, and an unplanned outage can lock out administrators. This matters most for servers that have no local console access. Prevent it by confirming the offline and failure behavior of each integration, and keeping a documented break-glass local account with its own access controls. Test the failure path on a staging host by stopping the MFA service and confirming what the login screen does.

Duo contract ending before export completes

If the Duo subscription ends before the user, phone and hardware token inventory is complete, the data you need for seeds and enrollment may no longer be reachable. Export and inventory depend on the Admin API and the plan that includes it, so confirm access terms with your Duo account team. Prevent it by exporting users, phones, tokens and integration settings while the contract is still active, and storing the files encrypted. Ask your Duo representative to confirm the end date and any read-only access period in writing.

Questions buyers ask before migrating from Duo to privacyIDEA

How much effort and cost should we expect for a Duo to privacyIDEA migration?

Expect the cost to come from four components: the servers and high availability design you run, the people who build and operate privacyIDEA, the enrollment and help desk work for your users, and any optional subscription. The main cost drivers are the number of users and hardware tokens, how many integrations you move (VPN RADIUS, Windows logon, Linux PAM, SSO), and whether you choose the NetKnights Enterprise Edition for support. The one-time work covers installation, resolver setup, token import and cutover. Recurring work covers patching, backups, monitoring and token lifecycle. Ask any quote to split these components and to state who performs each one. The privacyIDEA project is at privacyidea.org for details on its editions.

How long does a migration from Duo to privacyIDEA take?

The timeline depends on scope and sequencing rather than on a fixed duration. The work usually runs in phases: inventory users and devices from Duo, stand up privacyIDEA, connect user ID resolvers to your directory, import hardware tokens, pilot one integration, then move the remaining integrations and users in waves. Each wave needs time for enrollment and for fixing edge cases such as users with several phones. Your Duo contract end date sets the hard deadline, so agree the phase plan and the cutover date in writing before work starts. A fixed-scope statement of work from DeployOpen lists deliverables and timelines before anything begins.

What do we need from our own team for the migration?

Your team needs to provide several things. A directory owner must confirm the LDAP or Active Directory attributes and service account that privacyIDEA will use. A network owner must confirm RADIUS ports and which VPNs, firewalls and appliances will point to the new server. A Duo administrator must export the user and device inventory, as described in privacyIDEA's import documentation for the token side. A help desk lead must plan enrollment, support windows and fallback procedures. Security staff should review the seed handling and the retention of Duo data. Name these owners at the start, because most delays come from waiting for them.

Can we run the migration ourselves without outside help?

Yes, if your team has Linux, LDAP and RADIUS skills and time to run a pilot. privacyIDEA installs with pip or on Ubuntu and CentOS or RHEL-family systems, according to its installation documentation. The harder parts are hardware token import, the Duo Authentication Proxy replacement, Windows logon and fleet-wide PAM changes, plus the testing and cutover planning. An outside implementation partner can take some or all of that work under a written scope, and can also provide security testing before go-live. Decide early which parts you keep in-house, so your team builds the skills you will need to operate the system afterward.

Can we import our existing Duo hardware tokens into privacyIDEA?

Yes, for supported token types and file formats. privacyIDEA imports hardware token seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats through its Token import function, and it can import GPG-encrypted seed files with its own GPG key. The OATH CSV format covers HOTP, TOTP, OCRA and TAN tokens. Duo does not export token seeds in the simple way you might assume, so confirm with your Duo account team and your hardware token vendor which seed files you can obtain, and in which format, before you order replacements. Test each token type with a sample file in a staging instance. The privacyIDEA import documentation lists the field layouts.

Will push notifications keep working after we move to privacyIDEA?

Not with the same app. Push authentication in privacyIDEA uses the privacyIDEA Authenticator app, so Duo Mobile users must install it and enroll again. Users of standard TOTP and HOTP can keep apps such as Google Authenticator, which makes the OTP path easier to move. Plan re-enrollment for every Duo Mobile user, and keep a fallback method during the switch so no one is locked out. Confirm the push and mobile enrollment flow in a pilot with real devices before you set a cutover date.

What happens to our Duo data when the contract ends?

Duo's terms and your contract govern how Duo handles and deletes data at the end of service, so read those documents and ask your Duo account team to confirm the deletion process and the timing in writing. Before the end date, export the user, phone, token and integration inventory you need, and store it under your own retention policy. Keep authentication logs you must retain for audits, because the export options and retention periods belong to Duo's documentation and your compliance requirements. Confirm your records obligations with your legal and compliance teams.

What DeployOpen confirms before quoting a Duo migration

DeployOpen agrees the migration scope in writing before any work starts. For a Duo to privacyIDEA move, that scope lists each Duo export to be covered (users, phones, hardware tokens, integrations and any authentication log history the team wants to keep), each integration that must be re-pointed (web SSO applications, VPN and network devices behind RADIUS, Windows logon and Linux SSH), each hardware token format to be imported (OATH CSV, PSKC or Yubikey CSV, and whether any seed files are GPG-encrypted), and the parallel-run period during which Duo and privacyIDEA both accept logins. The written scope is also where the quote comes from, so a vague scope produces a vague quote.

Two things the reader should confirm internally before that conversation. First, confirm that the Duo plan in use includes Admin API access and that an administrator can create an API integration with read permissions for users, phones and tokens. Plan entitlements and rate limits change, so check the current Duo documentation and your own contract rather than relying on an earlier export. Second, confirm the privacyIDEA version that your security team has approved for production. Current releases are listed on the privacyIDEA releases page, and the chosen version determines which import formats, resolver options and installation path the implementation will use.

Also confirm who owns the help desk process during the parallel run, because that is where lockouts happen. Ask DeployOpen to document how users with no enrolled token are verified, how a lost hardware token is revoked, and when the Duo service can be switched off. Those answers belong in the signed scope, along with the acceptance tests for each integration and the rollback steps if a token format fails to import.

How DeployOpen scopes, runs and supports a Duo to privacyIDEA migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Duo to privacyIDEA migration, we start with a written scope that maps your Duo users, hardware tokens and RADIUS or Windows logon dependencies to privacyIDEA, then build and hand over the deployment in your environment.

How we scope

Inventory of Duo users, phones, hardware tokens and integrations taken from your own Admin API export
Mapping of each Duo factor to a privacyIDEA token type, with gaps such as Duo Mobile push flows called out
Written scope, deliverables and timelines agreed before work starts, with ongoing support available as a retainer

How we build

Installation of privacyIDEA in your environment, with user ID resolvers configured against your LDAP or Active Directory
Import of hardware token seed files in the OATH CSV, PSKC or Yubikey formats, handled under your key management rules
RADIUS and PAM integrations tested against your VPNs, network devices and Linux hosts before any cutover

How we hand over

Runbooks covering enrollment, token replacement, lockout recovery and help desk procedures for your staff
Configuration documentation and evidence for your compliance readiness reviews, prepared for your independent auditors
Knowledge transfer sessions so your team can operate privacyIDEA after the engagement closes

How we support

Retainer options for upgrades, patching, backups and ongoing privacyIDEA maintenance in your infrastructure
Continuous security testing of the MFA deployment and its RADIUS and LDAP endpoints, if included in scope
Post-cutover review of enrollment rates, failed logins and help desk tickets, agreed in writing