MFA requirements checklist

Offline use and recovery set requirements the platform must meet on day one, not after launch. A laptop that boots with no route to the MFA server, an air-gapped enclave with no network path at all, and a user who has lost a hardware key all force the same design question: what can someone still do when the second factor cannot be reached? Decide this before selecting a product. Confirm whether privacyIDEA's Windows credential provider and Linux PAM module can cache or bypass a second factor when the MFA server is unreachable, how long that cache lasts, and whether it applies to admin accounts. For FreeIPA, confirm how its OTP checks behave when the proxied RADIUS server is down, since that dependency is part of the design.

Recovery needs its own controls. Decide which secondary factors exist for each user population, such as one-time recovery codes, a second enrolled hardware token, or a supervised re-enrollment, and who may issue them. Specify the identity verification the help desk performs before resetting a token, including whether it requires a manager callback, an in-person check or a verified device. Record every reset in the audit log, because an attacker who calls the help desk is a common route around MFA. Confirm with each product's documentation how recovery codes are generated, stored and revoked, and whether a lost token can be disabled centrally across VPN, Windows and SSH at once.

Most lockout incidents start in these flows, so test them before go-live. Build a written test matrix covering a laptop with the MFA server unreachable, a lost hardware key, a replaced phone, a locked account after repeated failures, and a restored backup of the token store. Run each test with a real user account in a staging copy of production, and time how long each recovery takes. Ask your implementation partner to include these scenarios in the acceptance criteria of the fixed-scope agreement, so that offline and recovery behavior is verified in writing rather than assumed.

The fastest way to separate MFA platforms on a short list is to ask questions that have a verifiable answer, not questions that invite a marketing reply. Start with phishing resistance for the logins that matter most: ask the vendor or partner to demonstrate a FIDO2 or WebAuthn login for your admin accounts, VPN and core application, and to show which token types are accepted at each integration point. Push and OTP are not phishing resistant, so a platform that only proves push is not an answer to this question. Ask for the exact integration (RADIUS, Linux PAM, the Windows credential provider, or SAML and OIDC through Keycloak) and the test evidence for each one.

Next, ask how enrollment works at scale and during a help desk outage. Request the enrollment workflow end to end: who can enroll a token, whether users can self-enroll after identity verification, how a lost device is revoked, and what happens to a user who cannot reach the help desk. Ask how user stores are read and how changes sync. privacyIDEA, for example, resolves users through LDAP, SQL, SCIM and HTTP resolvers, so confirm which resolver you need, how often it refreshes, and whether a leaver in the source directory loses MFA access without manual cleanup. Also ask what happens to existing tokens during a migration from your current product: confirm which seed formats can be imported (privacyIDEA lists SafeNet XML, OATH CSV, Yubikey CSV and PSKC) and who holds the import keys.

Finally, ask how the platform behaves in failover and what auditors receive. Request the high availability design in writing, including how the authentication service and its database fail over, and what a RADIUS or PAM outage does to remote and local logons. Keycloak documents its own clustering designs and requires a synchronously replicated database for them, so ask for the equivalent detail from every candidate. For reporting, ask for a sample of the authentication log and the configuration export that an examiner would see. Last, ask which enterprise features sit behind a separate license. privacyIDEA states that its Enterprise Edition is available from NetKnights, and ZITADEL and authentik also publish licenses that differ by directory. Get the list of features your requirements depend on, and confirm in writing that they are included in the quoted price.

The two regulations most often cited for MFA design are the HIPAA Security Rule and the FTC Safeguards Rule, and they ask for different things from the same login system. Under the HIPAA Security Rule at 45 CFR 164.312, covered entities and business associates must implement access control with unique user identification, audit controls that record and examine activity in systems holding ePHI, and person or entity authentication. In practice, this means every clinician, contractor and service-connected vendor account needs its own identity in the MFA store, so shared logins and generic accounts must be removed or handled as exceptions before MFA is layered on. Confirm with your privacy and security officers whether the rule's authentication requirement is met by your chosen second factor or whether it needs to be documented as part of a broader access control design.

The FTC Safeguards Rule at 16 CFR 314.4 is more prescriptive on MFA. It requires covered financial institutions to implement multi-factor authentication for any individual accessing any information system, and to monitor and log the activity of authorized users. For the design, that means the checklist must cover every entry point (VPN, email, administrator consoles and core systems), and the MFA platform must write authentication events to a log that your team can retain and review. Decide early which systems are in the MFA scope, who approves exceptions, and where the event logs will be stored, because these choices determine the evidence you can show later.

DeployOpen prepares configurations, documentation and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Before you finalize the design, ask your assessor to confirm the exact scope, which systems count as in scope for each regulation, which log fields and retention periods they expect, and how they will test unique identification and authentication. Their answers should drive the acceptance criteria written into the statement of work.