Open source MFA for public sector: why PIV, contractors and legacy systems change the design
Public sector MFA design is driven by two questions: which logins must be phishing-resistant, and where the MFA server is allowed to run. Agencies that already issue PIV or CAC cards have a phishing-resistant factor in hand, so the real question is whether the MFA platform can validate the certificate chain and map it to a directory identity. For smartcard-heavy estates with many VPNs, Linux hosts and Windows logons, privacyIDEA is built around that model. It supports PIV and x509 smartcards, FIDO2 and WebAuthn, and integrations for RADIUS, Linux PAM and the Windows credential provider. For web SSO across many applications, Keycloak is the more common starting point. Neither is the default winner. The agency's login inventory decides which platform, or combination, fits.
Contractors without government cards and legacy systems need separate paths. Contractor identities usually need a phishing-resistant factor that the agency can issue, enroll and revoke, such as FIDO2 security keys tied to a sponsored directory account. Legacy applications that cannot speak SAML or OIDC typically go through RADIUS, the PAM module or privacyIDEA's REST API, which adds a control point without rewriting the application. Before design work starts, confirm with the agency which contractor populations exist, who sponsors them, and which systems accept smartcards or FIDO2 keys today. Then sort each login into one of three groups: phishing-resistant now, phishing-resistant after an application change, or OTP-only until retirement. The federal memo M-22-09 shapes which group comes first, so check its current requirements with the agency's security office.
Keeping identity data on government premises affects every component. privacyIDEA states that it keeps user data inside the operator's infrastructure, and Keycloak runs in whatever cluster and database the agency provides. An on-premises deployment in an agency-controlled facility may sit outside the FedRAMP cloud discussion, but confirm that scoping with the authorizing official before design is locked. Where criminal justice information is involved, the FBI CJIS Security Policy adds cryptographic module requirements that the partner must document. User-facing enrollment and recovery pages also fall under accessibility rules for state and local government web content, so ask the partner to test them against WCAG 2.1 Level AA early.
Which requirements shape a public sector MFA build
This table compares the federal, criminal justice, controlled information, defense and European requirements that most often shape a public sector MFA design. Read each row as a question to answer with your authorizing official or assessor before choosing tokens, hosting location and high availability. DeployOpen prepares systems and evidence but does not issue authorizations, so the agency's authorizing official or assessor makes the final determination.
| Requirement | Source | What it means for the build |
|---|---|---|
| Identification and authentication (IA-2) by impact level | NIST SP 800-53 Rev. 5 with SP 800-53B baselines: 149 controls and enhancements for low, 287 for moderate, 370 for high | Confirm the system's impact level first, since it sets how many enhancements apply, including MFA for privileged and non-privileged users. Ask the assessor which IA-2 enhancements they will test and what configuration evidence they expect from privacyIDEA or Keycloak. |
| Cloud-hosted MFA scope under FedRAMP | OMB M-24-15 and the FedRAMP Consolidated Rules for 2026 scope | If the MFA service runs as a cloud product that stores or processes federal information for an agency, FedRAMP scope may apply. A self-hosted service on government premises or in an agency-controlled account usually sits outside that scope, which the agency should confirm in writing. |
| Criminal justice information (CJI) encryption and scanning | FBI CJIS Security Policy v6.1, effective 26 June 2026, with 256-bit AES and FIPS 140-3 validated modules outside physically secure locations | Check that the MFA server, its database, token seeds and transport use FIPS 140-3 validated cryptographic modules where CJI is involved. Plan monthly vulnerability scanning of the MFA stack and confirm the required key lengths with the CJIS Systems Officer. |
| Controlled unclassified information on non-federal systems | 32 CFR 2002.14(h)(2) and NIST SP 800-171 | Contractors and partners handling CUI on their own systems may be asked to meet NIST SP 800-171 requirements. The MFA service that guards those systems inherits that scope, so document where it runs and who administers it. |
| Cloud use for defense contractor CUI | 32 CFR 170.17(c)(5) under the CMMC Program | A cloud-hosted MFA service that handles CUI for a CMMC Level 2 contractor must be FedRAMP Authorized at Moderate or higher, or meet equivalent requirements. Self-hosting inside the contractor's own assessed scope avoids that cloud condition but brings the hosting into the assessment. |
| NIS2 scope for public administration | Directive (EU) 2022/2555, Articles 2 and 3 and Annex I | Central government entities fall in scope regardless of size, and Member States may extend coverage to local administration. Entities working in national security, public security, defense or law enforcement are excluded, so confirm the status of each system before designing the MFA tier. |
Which open source platforms fit public sector logins
Public sector MFA usually starts with the credentials employees already hold, such as PIV cards, and with contractors who may have none. The platforms below cover different parts of that problem, so most agencies will combine two of them. Each card names the fit and the check to run in a lab before you commit.
privacyIDEA for smartcards and tokens
privacyIDEA is a self-hosted MFA server that supports PIV and x509 smartcards, FIDO2 keys, OTP tokens and RADIUS, with a PAM module for Linux and a credential provider for Windows logon. It reads users from existing LDAP or Active Directory stores and can import hardware token seed files. Its license is AGPLv3, so confirm with counsel how modifications you make would be distributed. Lab check: confirm that your agency's PIV certificate chain validates end to end in the version you plan to deploy.
Keycloak for web app federation
Keycloak is a common choice for putting OpenID Connect and SAML 2.0 applications behind one login, with identity brokering to upstream directories and identity providers. It is licensed under Apache-2.0 and suits agencies that want a single front door for many web applications. Smartcard and WebAuthn support depend on configuration and version, so check them rather than assume. Lab check: confirm the certificate-based and WebAuthn authentication flows you need in the exact release, and test them against your PIV cards.
ZITADEL for passkey-first logins
ZITADEL is an identity platform that lists passkeys (FIDO2 and WebAuthn), SSO, MFA, OpenID Connect and SAML 2.0 among its features, with multi-tenancy for separating agencies or programs. It is licensed under AGPL-3.0. It fits agencies that plan to move users toward passkeys and want tenant separation, but it is a newer choice for many public bodies than Keycloak. Lab check: confirm how it handles PIV-based sign-in and whether its directory connectors match your user stores.
FreeIPA for Linux-centric estates
FreeIPA combines a directory, Kerberos, certificate authority and OTP support in one identity system, which suits agencies running mostly Linux servers and Unix-style access. It can serve as the user store that other MFA components read from, and it simplifies SSH and sudo policy. Its Windows and web application integration is narrower than privacyIDEA or Keycloak. Lab check: confirm how it issues and validates the certificates your smartcard workflow needs, and whether Windows clients need an added component.
authentik for mixed directory environments
authentik is an identity provider with an MIT-licensed core, while its enterprise directory falls under a separate enterprise license. That split matters for procurement, because features in that directory need a different license review. It supports OIDC and SAML and suits agencies with mixed directory sources and modest app catalogs. Lab check: identify which features you need, confirm whether any sit in the enterprise directory, and validate PIV support against your target version.
Deployment patterns that keep MFA on government premises
Government MFA only stays on premises if the identity provider, the token server and the integration points all run inside the agency's boundary and survive failures without locking out staff. The six patterns below cover high availability, VPN failover, operating system logon, directory reuse, contractor separation and controlled upgrades, and each one shifts work to the team that runs the platform.
Keycloak high availability on premises
Both supported Keycloak high availability designs, a single cluster spread across availability zones and the multi-cluster v2 design, require a synchronously replicated database. For a government deployment, that means the database replicas must sit inside the agency's data centers or accredited enclave, and the team must test failover of the database before cutting over logins. Ask the implementation partner which database engines are in scope from the supported list, how replication lag is monitored, and who owns the failover runbook.
RADIUS failover for VPN access
VPN gateways such as OpenVPN, Fortinet and Palo Alto send second-factor checks to privacyIDEA over RADIUS, so a single RADIUS endpoint outage can block every remote employee and contractor at once. Configure at least two privacyIDEA nodes as RADIUS targets on each gateway and test what happens when the primary stops responding. Confirm with the gateway vendor how it handles timeouts and retries, and decide in advance whether any emergency access path exists and who can approve it.
PAM and credential provider integration
The privacyIDEA PAM module covers Linux logons and the Windows credential provider covers desktop and server logon, so one token policy can govern both. Roll out admin accounts first and keep service accounts that cannot answer a challenge on a documented exception list. Ask the partner how offline laptop logons are handled, what happens if the MFA server is unreachable during logon, and how break-glass accounts are kept outside the MFA path and audited.
LDAP and AD federation for existing identities
privacyIDEA reads users through LDAP, including Active Directory, and Keycloak can federate LDAP and AD users, so agencies usually keep their existing directory as the source of identity and add MFA on top. The design question is which system owns enrollment state, token records and group-based policy, and how disabled accounts in the directory are reflected in MFA within a defined time. Confirm service account rights, TLS on the LDAP connection and read-only access to the directory before go-live.
Separate realm or resolver for contractors
Contractors often lack PIV cards and sit outside the agency directory, so placing them in a separate Keycloak realm or privacyIDEA user ID resolver keeps their identities, token types and password policies apart from employees. This separation also makes access reviews and offboarding easier to evidence. Ask the partner how contractor sponsorship is recorded, which token types are allowed without a government-issued credential, and how contractor accounts expire when a contract ends.
Manual approval for operator updates
The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, so an upgrade does not reach the authentication path without a change record. Pair this with the Keycloak schema migration behavior: automatic migration runs at startup by default, while large deployments often apply SQL manually. Ask the partner to stage upgrades in a non-production environment that mirrors the database topology, and to keep a tested rollback for each change window.
How a public sector MFA rollout is phased
The sequence moves from knowing what systems and data are in scope to a documented, reversible production cutover and a handover of evidence the agency can give to its assessors. Each phase closes with a written output that the next phase depends on.
Scope the system inventory and data classification
The agency's security and identity staff, with the DeployOpen team, list every system that needs a second factor: VPNs, Windows and Linux logons, SSH and sudo, administrator consoles, email and web applications. Each system is tagged with the data it holds and whether it handles CUI or CJI. The output is a signed inventory that names an owner for each system and the directory it reads users from.
Confirm the baseline and CUI or CJI status
The agency confirms which control baseline applies to each system and whether any system is subject to the FBI CJIS Security Policy or to CUI safeguarding requirements for non-federal systems. Where a cloud service is involved, the team checks whether it holds a FedRAMP authorization at the required level. The output is a short written record of applicable requirements that sets the acceptance criteria for later phases.
Build and test in a lab with PIV and FIDO2
DeployOpen builds a non-production privacyIDEA or Keycloak environment inside the agency's network, connected to a copy of the directory. Test cases cover PIV and x509 smartcard login, FIDO2 security keys, lost-token recovery, and fallback when the MFA service is unreachable. The output is a test report with pass or fail results for each case, reviewed and accepted by the agency.
Pilot with administrator and remote-access accounts
The first live group is administrators and remote-access users, because they carry the highest risk and their access can be reviewed closely. The team monitors enrollment problems, help desk tickets and authentication failures for a period agreed in the written scope. The output is a pilot findings log and a set of configuration changes approved before wider rollout.
Define the contractor enrollment path
Contractors without PIV cards need a documented route to a phishing-resistant or otherwise approved second factor. The agency decides who sponsors each contractor, how identity is verified at enrollment, how hardware keys are issued and returned, and when access expires. The output is an approved enrollment procedure and a register of contractor accounts linked to their sponsors.
Integrate legacy applications and record exceptions
Legacy systems that cannot accept modern authentication are integrated through a gateway, a RADIUS or proxy path, or a scheduled retirement plan where possible. Any system that cannot meet the target is listed on an exception register with the owner, the compensating control, and a review date. The output is a complete integration record and an exception list that the agency's risk owners have accepted in writing.
Cut over to production with a tested rollback
Production cutover proceeds system by system, in the order set during scoping, with a documented rollback procedure for each change. The team confirms that the production MFA service is highly available and that backups and restore steps have been tested. The output is a cutover log showing each system's go-live date, verification results, and any rollback that was used.
Hand over configuration and audit evidence
DeployOpen delivers the configuration baseline, the access policy for each system, the test and pilot records, the exception register, and the logs that show authentication events. The agency's assessors or auditors use this package for their own testing, since DeployOpen prepares evidence but does not issue assessments. The output is a signed handover package and a schedule for reviewing it.
Evidence auditors and assessors ask for from MFA
This table lists the evidence items assessors commonly request for a self-hosted MFA deployment and the component that produces each one. Read it as a checklist to set up before an assessment, since most items must be generated during operation rather than assembled afterward. The main takeaway is that configuration baselines, enrollment records and authentication logs are only useful if they are captured continuously across the audit period.
| Evidence item | What it proves | Which component produces it |
|---|---|---|
| Configuration baselines and change records | Approved MFA policy and when each change was made, reviewed and approved | Keycloak Operator manual approval mode for upgrades, privacyIDEA policy exports, change tickets |
| Enrollment records tied to unique user IDs | Each factor is bound to one identifiable account, supporting unique user identification | privacyIDEA token list linked to LDAP or AD user ID resolvers, Keycloak user records |
| Authentication logs and audit trail retention | Who authenticated, with which factor, when and from where, retained for the required period | privacyIDEA audit log, Keycloak event logs and metrics, forwarded to a SIEM such as Wazuh |
| Failover test results | The MFA service keeps working when a node or site fails, with documented recovery time | Keycloak high availability test records, privacyIDEA failover runbook results, RADIUS fallback tests |
| FIPS validation status of cryptographic modules | Whether the modules used for authentication and transport are FIPS 140-3 validated for the target system | Operating system and crypto library certificate records, confirmed with the vendor or the validation database |
| Vulnerability scan reports | Monthly scanning of MFA servers and their dependencies, with tracked remediation | Scanner output from the chosen vulnerability management tool, applied to the MFA hosts and containers |
| Access control and privileged account records | Only authorized administrators can change MFA policy or tokens, with separation of duties | Keycloak admin role assignments, privacyIDEA admin realm settings, directory group membership exports |
What to ask an implementation partner for public sector MFA
Start with certificate handling, because PIV authentication is only as strong as the validation behind it. Ask how the partner configures privacyIDEA or Keycloak to validate PIV and x509 certificates against the agency's trust chain, which revocation method is used (CRL, OCSP or both), what happens when the revocation service is unreachable, and whether a revoked card is rejected at the next login rather than at the next token expiry. Ask who maintains the trust anchors when the agency's certificate authority rotates, and who tests that change before it reaches production. Ask for the test cases that prove a revoked card and an expired card are both refused, and for the results from a run in your own environment, not a demonstration system.
Next, establish the boundary. Ask whether the build, the configuration repository and the administrative consoles run inside the agency's accreditation boundary, and which of those components, if any, reach outside it for updates, licensing or telemetry. Ask who holds the hardware key inventory, meaning the serial numbers, assignment records and the procedure for destroying or reissuing lost FIDO2 keys, and whether that register lives on agency systems. For contractors without PIV cards, ask how their identities are onboarded from the sponsoring agency's source, how access is limited to the systems their contract covers, and how offboarding runs on contract end, including revoking tokens and removing directory entries on the same day. Confirm that the partner's staff accounts are themselves covered by the same MFA policy.
Finally, make the partner show its work on validation and evidence. Ask which FIPS 140 validated modules the chosen versions of privacyIDEA, Keycloak and the operating system rely on, and ask for the validation certificate numbers and the exact module versions in use, since a validated library in one release may not be the one deployed. Ask for the update and patching model: who applies security releases, how quickly, whether the partner tests them on a staging copy first, and how a rollback works. Ask who signs off each evidence pack, who the named reviewer is on the agency side, and whether the partner's work is reviewed by an independent assessor before it reaches the agency's authorizing official. DeployOpen prepares controls and evidence; the assessor and the authorizing official decide whether they are sufficient.
Common questions about public sector open source MFA
What drives the cost of a public sector open source MFA project?
The main drivers are the number of systems to integrate, the work needed to validate PIV and smartcard certificates, the enrollment volume, and the high availability design. Each integration (VPN, Windows logon, Linux PAM, SAML or OIDC applications, custom web apps) has its own configuration and testing effort. The software itself is typically free to download under its license, so the spend goes to people, servers, hardware keys and support. Ask for a quote that separates one-time work (design, integration, enrollment, testing, documentation) from recurring items (support subscriptions, upgrades, retained operations), and confirm which of those the open source license does not cover. Hardware FIDO2 keys and smartcard logistics are often a larger line item than expected, so ask for them as separate lines.
How long does an open source MFA build take for an agency?
The duration is set by the written scope, not by a general rule. Timelines depend on how many systems are in the first phase, whether identity sources such as Active Directory or LDAP are clean, how many change windows the agency's operations team allows, and whether a pilot group must run before wider rollout. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the right way to get a number is to define the first phase precisely and ask for a schedule against that phase. Ask any partner to show the dependencies on your side, such as firewall changes, certificate authority access and approvals for production windows, because those often control the calendar more than the software does.
What does the agency need to provide before an MFA project starts?
The agency needs to supply several things before design can begin:
- The identity sources of record, with directory owners and the current state of user attributes
- Named owners for each system to be protected, including VPNs, Windows and Linux fleets, and web applications
- Access to test environments and a defined change window for each production step
- The PIV or smartcard trust chain, with the certificate authority owners who can confirm revocation and validation settings
- A decision on who approves enrollment and recovery requests, and who staffs the help desk
Missing items usually show up as delays rather than as technical failures, so confirm them in the scope document with named people and dates.
Can our own IT staff run open source MFA without an outside partner?
Many agencies have capable staff who can operate the platform once it is built, but the first build and the integrations are where skills usually run short. The work involves directory integration, certificate validation for PIV cards, PAM and Windows credential provider configuration, high availability, and evidence collection for assessments. Ask internally who will own patching, backup and restore testing, token administration and incident response after go-live, and whether that team has time for it. A partner can build and document the system so your staff can run it, and retainers are available for ongoing support and upgrades. The right split is a question for your own skills review.
Does self-hosting open source MFA mean we avoid FedRAMP?
Not automatically. FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. The FedRAMP Consolidated Rules for 2026 state that systems used only for a single agency's operations on cloud infrastructure, and not offered as a shared service, are out of scope. An MFA platform that runs on your own servers in government premises is generally not a cloud service in that sense, but whether it is in scope depends on where it is hosted, who operates it, and whether any part is delivered as a shared service. Confirm the classification with your authorizing official and assessor before design, and document the hosting model in your system boundary. DeployOpen prepares controls and evidence for assessments but does not issue authorizations or certifications.
What happens to legacy systems that cannot support MFA?
Legacy systems that cannot accept a second factor need a compensating path rather than being left open. The usual options are to place them behind a gateway or reverse proxy that enforces MFA before access, to route their logins through a SAML or OIDC front end where the application supports it, or to restrict access by network segment and privileged role until the system is replaced. Each option carries its own risk, and the decision should be recorded with the system owner and the risk owner. Ask any partner to inventory legacy systems early, to classify them by data sensitivity and exposure, and to show the compensating control and its evidence for each one. Replacement timelines belong in your own roadmap, not in the MFA scope.
How DeployOpen scopes and supports public sector MFA
DeployOpen plans, implements, hardens, documents and supports self-hosted MFA platforms inside the agency's or municipality's own infrastructure, whether that is a government data center, a state or municipal cloud tenancy, or an air-gapped network. For a public sector MFA project, that means the privacyIDEA or Keycloak servers, their database, the PIV and FIDO2 validation path, the RADIUS, PAM and credential provider integrations, and the logging that feeds your SIEM all run where your security office can inspect them. Scope is agreed in writing before work starts, and the written scope is what sets deliverables, timelines and the quote. Because the request usually spans several user populations (employees with PIV cards, contractors without them, and legacy applications that only accept a password), the scope document should list each population, each application and the token type assigned to it, so that the boundary of the project is clear before any configuration begins.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations, authorizations or certifications. A FedRAMP, CJIS, NIST SP 800-53 or state-level assessment is performed by the authorizing official, an assessor or an independent auditor. Our role is to deliver the configuration baselines, change records, access review extracts and test results those parties will ask for, and to confirm early with your assessor which evidence format and which control mappings they expect. Security testing of the MFA deployment itself, including configuration review, attempts to bypass second factors and checks of the enrollment and recovery workflows, can be included as a separate fixed-scope item. Ongoing support, upgrades and continuous testing are available as retainers, which suits agencies that must keep a patched and documented stack through several release cycles.
