How to run an MFA RFP without buying the wrong second factor
Run the MFA RFP questions as one scored evaluation: send every bidder the same written scope, score written answers against that scope, and require live demonstrations of the riskiest items before any contract is discussed. The scope should list the systems to cover first (VPN, Windows and Linux logon, SSH and sudo, and web applications), the user stores that hold identities today, and the token types users already carry. Many buyers are replacing a current MFA product, so the scope must also name the existing tokens and the migration path for them, because a platform that cannot import or re-enroll those tokens will shift cost onto the help desk on cutover day.
Keep the questions neutral across the platforms in the Topic Facts. privacyIDEA, Keycloak, FreeIPA and ZITADEL each cover different parts of the problem: privacyIDEA focuses on token types and RADIUS, PAM and credential provider integrations, Keycloak on OpenID Connect and SAML single sign-on for web applications, FreeIPA on Linux and Kerberos identity with OTP tokens, and ZITADEL on passkeys in a multi-tenant identity platform. Ask each bidder to map every required system to a specific integration and to say which parts are native, which need a plugin and which need custom work. Do not accept a single answer such as 'supported' for everything. The right answer depends on your systems and your users, so the scoring sheet should reflect those, not a vendor's feature list.
Reserve the most time for the questions that decide whether the second factor holds up: phishing resistance (which token types can be phished and which cannot), lockout and recovery, behavior when the MFA service is unreachable, and high availability design. Ask bidders to demonstrate a lockout, a recovery through the help desk, and a failover while logins continue. Also ask for written answers on licensing, support terms and the upgrade cadence of the software, and confirm each vendor's release history directly with the project or vendor, since release and support dates change. Reject answers that defer these points to a future roadmap, because those are the points that fail in production.
Which questions to ask about phishing resistance, integrations and enrollment
Which MFA methods are phishing resistant, and which can be phished?
FIDO2 security keys and passkeys (WebAuthn) are the phishing-resistant methods, because the browser or key binds the credential to the site origin. Push approvals, TOTP, HOTP and SMS can be phished or relayed, so they are not phishing resistant. Ask each bidder to map every method to the logins in scope and to state which methods they will not support in your target environment. privacyIDEA supports FIDO2 and WebAuthn passkeys and hardware keys, PIV and x509 smartcards, push, TOTP and HOTP, TiQR, SMS, email and registration codes. Ask the vendor to name the release tested, then confirm in a lab that a phishing simulation against a FIDO2 login fails as designed.
Will push and TOTP work with the authenticator apps our users already have?
Standard TOTP and HOTP codes work with apps such as Google Authenticator, so existing users can keep them. Push notifications need the privacyIDEA Authenticator app, so a push rollout means app distribution and enrollment on every device. Ask bidders whether they expect users to change apps, how many apps they will support at launch and whether push can be disabled per group. Confirm in a lab with a pilot group using both the standard app and the vendor app.
Which Linux, Windows, VPN and web integrations does the product ship with?
Ask for a written list of integration points tied to version numbers, not a general statement of support. For privacyIDEA, the documented points are a PAM module for Linux, a credential provider for Windows logon, identity provider plugins for Keycloak, AD FS, Shibboleth and SimpleSAMLphp, RADIUS for VPNs such as OpenVPN, Fortinet and Palo Alto, and the REST API for web applications. Ask how each is tested, which versions of your operating systems and VPN firmware were checked, and who maintains the connector after upgrades. Confirm each integration in your own environment before it is counted as covered.
How does MFA connect to our existing directories and identity provider?
Ask which user stores the product reads directly and whether it writes back to them. privacyIDEA reads users through resolvers for flat files, LDAP (including Active Directory), SQL, SCIM and HTTP. Ask bidders how they will handle service accounts and automation that cannot answer a second factor, which groups are exempt, and how a directory change propagates. Ask whether SAML or OIDC login flows keep working when the second factor is added, and confirm with a test user in each directory.
How do we enroll thousands of users and migrate tokens from our current product?
Enrollment at scale depends on self-service enrollment, help desk tooling and the import path for hardware tokens. privacyIDEA can import hardware token seed files in SafeNet XML, OATH CSV, Yubikey CSV and PSKC formats, and can import GPG-encrypted seed files. Ask bidders to explain the import workflow for each format, how seeds are protected in transit and at rest, and how they will move tokens without re-enrolling every user. Ask for the enrollment duration per user and per group as they measured it, and confirm with a sample file in a staging system.
What happens when a user is locked out or loses a device?
A good answer names the lockout threshold, the unlock path, the recovery path for lost devices, and who approves recovery. Ask bidders whether recovery uses a second enrolled token, a time-limited code, or help desk verification, and how each path is logged. Ask how they prevent the recovery path itself from becoming the weakest login. Confirm in a lab that a lost hardware key can be revoked, that a replacement can be enrolled, and that the event appears in the audit log.
How is the MFA service made highly available, and what fails when it is down?
Ask for the high availability design, the number of servers per site, the database replication model and the failover test results. For Keycloak, the documented high availability designs require a synchronously replicated database. For privacyIDEA, ask how RADIUS and Windows logons behave when the MFA server is unreachable, and whether offline or cached logons are supported for laptops. Ask whether the design survives a site outage and who runs the failover drill. Confirm each claim with a scheduled failover test in your own network before go-live.
What do the licensing, support and upgrade terms cover in our partner quote?
Ask which parts of the stack are open source and which are paid, because enterprise editions and vendor distributions carry separate terms. privacyIDEA is licensed under AGPLv3, and an Enterprise Edition is available from NetKnights. Keycloak is Apache 2.0, and Red Hat build of Keycloak is a supported distribution with its own subscription. Ask whether support hours, patch windows, upgrade work and security response are in the fixed scope or a separate retainer. DeployOpen plans, implements, hardens and supports self-hosted open-source platforms under written scope, and ongoing support is available as a retainer. Ask for the written scope before comparing quotes.
Asking whether a second factor is phishing resistant
Start by asking each bidder which second factor they would recommend for each login, and why. OTP codes and push approvals can be phished because the user is the only thing standing between an attacker and the login: a convincing lookalike page can relay a six-digit code or prompt the user to approve a push, and the attacker then replays it within its validity window. Push fatigue attacks add a further path. FIDO2 security keys and passkeys work differently. The browser or authenticator binds each credential to the origin (the exact site domain) that registered it, so a lookalike domain receives no usable signature. The private key never leaves the device, and nothing a user types can be captured and reused. Ask bidders to explain how their platform enforces this binding for every relying party, not just for the login pages they demonstrate.
Ask which logins will move to phishing-resistant methods first and what order they propose. A credible answer names the systems that carry the most privileged or externally reachable access, such as administrator consoles, remote access gateways and identity provider admin sections, and explains how each will be enforced through the platform's policy engine rather than through a per-application setting. Ask whether the platform can require a specific authenticator class for a given application or group, and whether that policy applies when users sign in through an external identity provider or a legacy protocol. Ask how the vendor or partner will confirm the origin binding works for each integration on your own domain names, since relying party identifiers are set per application and a misconfiguration can weaken the control without any visible error.
Ask what happens to users who cannot use a hardware key or a platform passkey, such as contractors without company devices, staff with mobility limits, or shared workstation users. Require a written fallback design: which alternative methods are permitted, whether they are limited to specific applications or roles, how long they remain available, and who approves an exception. Ask whether a fallback path can be used to reach the same protected application, which would undo the protection, and how the platform logs the method used at each sign-in. Also ask about the cost of hardware keys, replacement logistics, and who carries recovery when a key is lost. Confirm these points against the platform's documentation and the bidder's written scope, and see the FIDO2 and passkey page for the full design and rollout detail.
Availability, lockout and recovery questions by deployment model
When the client runs the MFA platform on its own servers, the buyer owns the availability design and must test it. Ask how each integration behaves when the MFA service is unreachable, and whether the answer differs for VPN, Windows, Linux and web logins. Keycloak documents three high availability designs, and each supported design needs a synchronously replicated database, so ask which database engine and replication method the proposal uses and who tests failover.
- Unreachable server behavior: Ask whether each integration fails open or fails closed, and which accounts keep a local fallback during an outage.
- Lockout thresholds: Ask how failed attempts are counted, how long lockouts last, and whether an administrator can unlock an account without a directory change.
- Help desk recovery: Ask how a user with a lost token is verified before enrollment resets, and where that action is logged.
- Restore effects: FreeIPA's backup documentation warns that restoring an outdated backup into an active replica topology can break replication, so ask for the restore runbook and whether it has been rehearsed on a copy of the production topology.
- Replica placement: Ask how many replicas run in each site and which server holds certificate renewal and CRL publication by default.
Confirm each answer in a test window, not only in the proposal.
In a partner-run model, the MFA platform runs in the client's own cloud account, but the partner operates it day to day. Availability and recovery responsibilities are split between the two parties, so the contract and runbooks must say who acts at each step. Ask for the cloud layout in writing: which zones host the database and application nodes, and how the database replicates between them.
- Shared responsibility: Ask which party detects an outage, which party restores service, and what the client must approve before a failover or restore.
- Database replication: Ask which replication mode the database uses, because Keycloak's supported high availability designs depend on synchronous replication. Ask how a zone failure is handled.
- Access for recovery: Ask how partner engineers gain access to the client's cloud during an incident, and whether that access is time-limited and recorded.
- Help desk and lockouts: Ask whether the client's own help desk can unlock users and reset tokens without a partner ticket, and what the escalation path is when it cannot.
- Backup location and restore tests: Ask where backups are stored, who holds the keys, and how often a restore into a separate environment is tested.
Request the most recent restore test record and the runbook for each failure scenario before signing.
In an air-gapped network, there is no cloud service to fall back on and no external push or SMS channel. Hardware OTP tokens and FIDO2 keys verified by an on-premises server are the usual second factors, so the availability design must cover the MFA server, its database and its time source inside the enclave. Ask the vendor to confirm every dependency that reaches outside the enclave, including updates, certificate sources and time synchronization.
- Offline operation: Ask which login paths work with no connection to any external service, and which features, such as push, are unavailable by design.
- Local redundancy: Ask how many replicas run inside the enclave, where they sit, and how a failed replica is replaced without internet access.
- Break-glass access: Ask how a locked-out administrator regains access, who authorizes it, and how the event is recorded for later review.
- Restore from media: Ask how backups leave the enclave, how they are verified, and how a restore is sequenced so an outdated copy does not overwrite a live replica.
- Token recovery: Ask how a lost hardware token is replaced and how seed files are imported and protected during that process.
Confirm that the restore procedure works using only media and tools that exist inside the enclave.
How to plan token migration from the current product
This sequence moves users from an existing MFA product to the new platform without a lockout gap, keeps every token type accounted for, and ends with documented evidence that the old product is no longer trusted for any login.
Inventory token types and user stores
Before any bidder is shortlisted, the buyer lists every token type in use (hardware OTP fobs, software TOTP, push, SMS, smartcards, FIDO2 keys) and every user store the current product reads from, such as Active Directory, LDAP or a SQL table. Count tokens by type and by owner, and flag shared or service-account tokens. The output is a token register that bidders must answer against. Done when each token type has an owner, a count and a named migration path, including the ones that cannot move.
Confirm seed file formats and export paths
For hardware OTP tokens, ask the current vendor how seeds can be exported and in which format. Ask each bidder to confirm, in writing, which formats their platform imports. For privacyIDEA, the documented import formats are SafeNet XML, OATH CSV, Yubikey CSV and PSKC, and GPG-encrypted seed files can be imported with the platform's own GPG key. Tokens whose seeds cannot be exported must be listed for re-enrollment. Done when every token type in the register is marked as importable, re-enrollable or retired.
Define seed file transfer and key handling
Ask bidders who performs the seed file transfer: the buyer's staff, the bidder's engineers, or the current vendor under a written instruction. Require that seed files are encrypted in transit and at rest, that decryption keys are held by a named role, and that files are destroyed after successful import with a record of the destruction. Ask who holds the GPG private key and how it is rotated. Done when a written transfer procedure names each party, each key holder and the destruction method.
Migrate users through a pilot group
Select a pilot group that covers each token type and each user store, usually including an administrator group and a population that logs in through the VPN and Windows. Import seeds for the pilot, enroll new methods for users who cannot move seeds, and run real logins for each target system. Track failed logins, help desk tickets and lockouts against the pilot. Done when the pilot has produced a written list of defects, each resolved or accepted, and the buyer has signed off on the lockout and recovery steps.
Run old and new methods in parallel
Keep the current product active for every system until the new platform has handled logins for that system without incident. Enable the new method as an additional or fallback factor where the target system supports it, and expand population by population. Confirm with each bidder how the platform handles time drift for imported OTP tokens and how it records which factor was used. Done when each system has a dated cutover record and the old product still accepts logins only as a documented fallback.
Retire the old product and collect evidence
Disable the old product's authentication for each system, remove its integration points, and revoke its administrative access. Ask bidders to describe how the old product's seed data, logs and configuration are archived or destroyed, and who approves that step. Keep the retirement record with the token register, the import logs and the decommissioning checklist. Done when the old product has no active authentication path, its data is disposed of or archived under the agreed procedure, and the evidence package is filed with the buyer's compliance records.
Answers that should slow down an MFA decision
Most weak MFA proposals share a pattern: a broad claim is made where a specific answer belongs. The cards below name six such claims, each with the follow-up question that separates a credible answer from a sales answer. Ask for written, system-specific detail on every one before scoring vendors or partners.
Every method is phishing resistant
A proposal that lists OTP, push, SMS and passkeys under one heading has not separated phishing-resistant methods from phishable ones. Push prompts and one-time codes can be relayed by a fake login page, while FIDO2 and WebAuthn bind the credential to the site origin. Ask which login paths use phishing-resistant factors, which fall back to OTP, and who can approve that fallback.
No named integration for systems in scope
Ask for each system you need to protect (VPN concentrator, Windows domain, Linux SSH, web applications, admin consoles) and the exact connector, protocol or PAM module that covers it. A general claim of compatibility with SAML, OIDC or RADIUS does not show that a specific appliance firmware or Windows logon path works. Request a written integration matrix and a test plan for each item.
No written recovery and lockout process
Lost devices, failed enrollments and locked accounts generate most help desk tickets after go-live. Ask for the written steps to re-enroll a user, who verifies identity before a token is reset, how many failed attempts trigger a lock, and how an administrator unlocks an account without bypassing MFA. A proposal that answers only with a feature name has not designed the process.
Availability without a failure scenario
High availability diagrams do not show what happens when the MFA service, its database or the network path to it fails. Ask which logins keep working, which fail closed, and how long a user can be locked out during a planned upgrade. For Keycloak, ask how the database is replicated, since its documented high availability designs require a synchronously replicated database.
Token migration treated as a footnote
Moving users from an existing hardware or software token product is often the hardest part of the project, and it is rarely in the first pricing draft. Ask which token formats the platform can import, whether seed files can be exported from the current vendor, how enrollment is staged across users, and what happens to tokens that cannot be migrated. privacyIDEA documents import formats such as OATH CSV and PSKC, which is a starting point for that question, not an answer.
Licensing and support terms not in writing
Open-source core licenses, enterprise add-ons and support subscriptions are often priced and scoped separately. Ask which features sit under a separate commercial license, what support response commitments are written into the contract, who provides security patches, and how upgrades are scheduled. Confirm the license of each component you plan to run, since some projects split core and enterprise code under different terms.
How to score MFA vendor and partner responses
This table lists the criteria to score MFA vendor and partner responses, the evidence to require for each, and the failure pattern to test for. Use it to build a scorecard, then set the weights yourself with your risk owners, since no weighting is supplied here. A response that states a capability without evidence should score lower than one backed by a demo, a test result or a reference design.
| Criterion | Evidence to require | Where responses usually fail |
|---|---|---|
| Phishing resistance | Named authenticator types (FIDO2 security keys, passkeys, smartcards) and which logins can enforce them, with a demo against your IdP | Push or OTP described as phishing resistant, or passkeys listed without stating which apps accept them |
| Integration coverage | Written list of supported integration points (RADIUS, Windows logon, Linux PAM, SAML, OIDC, REST) mapped to your systems, with version tested | Generic claims of support that rely on custom scripting not in the quote |
| Token types and user migration | Import formats for existing seed files, tested sample import, and rules for keeping current apps or tokens during cutover | Migration described only as possible, with no test on a sample of your tokens |
| Enrollment at scale | Bulk enrollment workflow, self-service steps, help desk tooling and expected volume handling in a test environment | Enrollment shown only for a single user in a demo tenant |
| Lockout and recovery | Documented lockout thresholds, recovery paths for lost keys, and an audited identity proofing step for recovery | Recovery depends on a single administrator or on SMS or email that the attacker may control |
| Availability design | Reference topology for each site, failover behavior when the MFA server is unreachable, and the database replication model | High availability described without naming the database, the quorum rule or the offline fallback |
| Logging and audit evidence | Sample audit log export showing authentication events, admin changes and token assignments | Logs that cannot be exported to your SIEM or that omit the reason for a denied login |
| Licensing and support | Written license terms for the core and any enterprise components, support hours, upgrade policy and escrow or exit terms | Enterprise features placed in a separate license without stating which features the quote depends on |
What drives cost and effort in an MFA implementation quote
The biggest cost driver is usually the number of systems to integrate, not the MFA software itself. Each VPN, Windows or Linux login path, SSH entry point, and web application needs its own configuration, testing, and rollback plan. A quote should list every system by name, the protocol it uses (RADIUS, the Windows credential provider, the PAM module, SAML or OIDC), and whether that integration is in scope. Servers and high availability add a second cost layer: a production MFA service needs redundant nodes and a database that can fail over, and the quote should state how many nodes, where they run, and who maintains the database. Keycloak's documentation, for example, requires a synchronously replicated database for its supported high availability designs, so that work belongs in the scope.
Recurring cost sits in people and subscriptions, and it is easy to underestimate. Hardware keys, enrollment sessions, and help desk time for lost tokens and recovery requests repeat across the life of the platform. Ask the bidder to separate one-time work (design, integration, token import, hardening, documentation) from recurring work (patching, upgrades, token logistics, support). Open-source components carry no license fee, but some vendors sell paid support or enterprise editions. privacyIDEA's Enterprise Edition is available from NetKnights, and Red Hat sells a supported Keycloak distribution, so the quote should name any subscription it assumes and its term. Confirm whether the client or the implementer holds those subscriptions.
DeployOpen works from a written, fixed scope, and the quote should be the scope. Most engagements are fixed-scope, with scope, deliverables, and timelines agreed in writing before work starts. Ask for a quote that lists the systems in scope, the token types and user stores, the high availability design, the acceptance tests, the training and documentation deliverables, and the exclusions. Ask what is not included, such as ongoing support, upgrades, or the client's own help desk staffing. Compare quotes on that written scope rather than on headline totals. For a breakdown of cost components by delivery model, see the MFA cost page.
How DeployOpen scopes, delivers and supports MFA evaluations
DeployOpen helps organizations turn MFA RFP questions into a written scope, then plans, implements, documents and hands over a self-hosted open-source MFA platform inside the client's own infrastructure. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Map each RFP question to the systems, user stores and login paths it affects, such as VPN, Windows, Linux, SSH and web apps.
- Record the phishing resistance target, token types and offline needs for each user group in the written scope.
- Agree in writing which platform questions are answered by testing in a lab and which by vendor or partner confirmation.
How we build
- Deploy the candidate MFA platform in the client's cloud account, data center or air-gapped network, following the agreed design.
- Test enrollment, lockout, recovery and failover scenarios against the questions in the RFP, and record the results.
- Configure and harden integrations, then document token migration steps and the configuration that supports each control.
How we hand over
- Deliver architecture documentation, runbooks for enrollment and recovery, and the configuration evidence the client needs for assessments.
- Provide a written comparison of candidate platforms against the RFP questions, with open items marked for the client to confirm.
- Walk the client's operations and help desk teams through administration tasks before handover is marked complete.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately in writing.
- Review vendor and project release notes for security fixes and agree on an upgrade approach with the client.
- Prepare systems and evidence for compliance assessments. Independent auditors and certification bodies issue the actual conclusions.
