Self-hosted MFA for VPNs, Windows and Linux logins, SSH and web apps with privacyIDEA, Keycloak, FreeIPA or ZITADEL, and how phishing resistance, token types and regulations change the design.
Adding a second factor to OpenVPN, Fortinet, Palo Alto and other VPNs through RADIUS with privacyIDEA or FreeIPA: user stores, token enrollment, push versus OTP, failover so a RADIUS outage does not lock out remote staff, and logging for audits.
Requiring a second factor at Windows desktop and server logon and RDP with the privacyIDEA credential provider: offline logons for laptops, admin accounts first, enrollment at scale and what happens when the MFA server is unreachable.
Protecting SSH and sudo on Linux fleets with FreeIPA OTP or the privacyIDEA PAM module: central policies instead of per-server setups, service accounts and automation that cannot use MFA, and how SSH certificates fit alongside.
Why OTP and push can be phished and how FIDO2 security keys and passkeys are not, using Keycloak WebAuthn, privacyIDEA or ZITADEL: which logins can move first, hardware key logistics, recovery, and the federal M-22-09 requirement that drives many projects.
Second factors that work with no cloud service: hardware OTP tokens and FIDO2 keys verified by an on-premises privacyIDEA or FreeIPA, importing token seed files, no push or SMS, and keeping the MFA server highly available inside the enclave.
Clinicians on shared workstations, remote access to EHRs and vendor logins: what the HIPAA Security Rule says about authentication and MFA, fast re-authentication without slowing care, and deploying privacyIDEA or Keycloak in hospital networks.
The FTC Safeguards Rule requires MFA for anyone accessing information systems at covered financial institutions, and bank examiners expect it too. This page covers coverage of VPN, email, admin and core systems with self-hosted MFA and the evidence to keep.
Agencies and municipalities with PIV cards, contractors without them and legacy systems: smartcard and FIDO2 support in privacyIDEA and Keycloak, phishing-resistant targets from M-22-09, and keeping MFA infrastructure on government premises.
What IA-2 and its enhancements require for organizational users, including MFA for privileged and non-privileged accounts and replay resistance, and how self-hosted privacyIDEA, Keycloak or FreeIPA implement and evidence it for federal systems.
CIS Safeguards 6.3, 6.4 and 6.5 require MFA for externally exposed applications, remote network access and administrative access. This page maps each to a self-hosted MFA component and the order to roll them out.
SOC 2 does not name MFA as a criterion, but auditors test logical access controls under CC6. This page covers where self-hosted MFA is expected in practice, which systems to cover first and the configuration evidence to keep for a Type 2 period.
Requirements for an MFA platform: token types (FIDO2, smartcard, TOTP, push), integration points (RADIUS, Windows, Linux PAM, SAML and OIDC), user stores, enrollment and recovery, offline use, high availability and reporting.
Questions for MFA vendors and partners: phishing resistance, supported integrations, enrollment at scale, lockout and recovery process, availability design, token migration from the current product, licensing and support terms.
Cost components of MFA on self-hosted open source versus a partner-run deployment versus per-user SaaS: servers and high availability, hardware keys, enrollment and help desk effort, integration work per system and support subscriptions.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.