Open source MFA for SOC 2: what auditors test under CC6
SOC 2 does not name multi-factor authentication as a criterion, but CC6.6 requires logical access security measures that protect against threats from sources outside the system boundary, and the points of focus under that criterion include requiring additional authentication or credentials. For a scope that includes VPN access, admin consoles and SaaS logins that still rely on passwords alone, an auditor will ask how remote and privileged access is protected from outside the boundary. Self-hosted MFA is the usual way to answer that question, because it puts the second factor under your own control and produces logs you can hand to the auditor. The 2017 Trust Services Criteria (TSC) present points of focus as characteristics that help you design and evaluate a control, not as separate requirements, and not every point of focus has to be addressed. What matters is that your MFA control is designed to meet CC6.6 for the systems in scope, and that it actually operates throughout the Type 2 period, when the auditor tests operating effectiveness over time.
Start by writing down which access paths reach the system boundary and which accounts can use them. Typical paths include VPN and remote desktop, administrative consoles, cloud management portals, SSH to production hosts and SaaS applications that hold customer data. Confirm with your auditor how they will sample these paths, because a gap in one path is often the finding, even when the others are well covered. Decide which systems MFA will cover first, usually remote access and privileged accounts, and record the decision with its rationale, since the auditor will ask why some paths were excluded or deferred. The control description should name the platform, the enforcement point (for example, a RADIUS or SAML integration), the account population and the exception process, so that the design can be evaluated without interviews.
Which CC6 points of focus MFA must support and how to configure it
This table maps CC6 logical access points of focus to what self-hosted MFA must do and where each platform is configured. Read each row as a design question to settle with your auditor before the Type 2 period begins, since points of focus are characteristics to consider rather than separate requirements. The main takeaway is that the MFA design, enforcement policy and evidence all need to match the systems in your SOC 2 scope.
| Requirement area | What MFA must do | Configuration and evidence to keep |
|---|---|---|
| CC6.6 boundary access from outside the system | Require a second factor for remote access paths such as VPN, ZTNA gateways and externally reachable web apps before a session is granted. | privacyIDEA RADIUS or SAML plugins, or Keycloak browser flow with OTP or WebAuthn required. Keep policy exports and a sample of successful and failed remote logins. |
| Protecting authentication credentials | Store seeds, token secrets and MFA enrollment data so they are not readable by general administrators, and keep user factors tied to verified identities. | Restrict database and config file access, record who changed token assignments, and confirm where TOTP seeds and signing keys are held. Confirm encryption settings with your vendor. |
| Requiring additional authentication for privileged and sensitive apps | Enforce MFA on admin consoles, production SSH and sudo, and systems holding customer data, not only on the VPN. | FreeIPA OTP or the privacyIDEA PAM module for Linux, Keycloak required actions for admin realms. Keep a list of in-scope systems mapped to the enforcing policy. |
| Restricting access by policy | Apply MFA by user group, network location or application, and document exceptions such as service accounts that cannot use interactive MFA. | Keycloak conditional authentication or privacyIDEA policies by realm, group and client. Keep exception approvals with owners and expiry dates. |
| Monitoring and logging of authentication activity | Record successful and failed MFA events, token enrollments, resets and policy changes with user identity and timestamps. | Forward privacyIDEA audit entries and Keycloak events to a central log store. Keep samples across the full Type 2 period, not only at the start. |
| Benchmarks auditors may reference (not SOC 2 requirements) | SP 800-63B-4 and CISA guidance describe phishing-resistant options and number matching. SOC 2 does not require them, but auditors may ask how your design compares. | Document the decision for each login path and confirm with your auditor whether phishing-resistant options such as FIDO2 are expected for your scope. Treat this as a design choice to agree in advance. |
Which systems to cover first for a SOC 2 scope
Remote access entry points rank first because they sit on the system boundary, where CC6.6 expects protection against threats from sources outside the system. VPN concentrators, and any zero trust network access gateway that replaces them, accept logins from anywhere on the internet, so a stolen password there gives a direct path into the environment. Auditors usually look for a clear answer to whether every remote path requires a second factor, and they test whether that answer holds in practice.
- Entry points: List every VPN, ZTNA gateway, remote desktop gateway and reverse proxy that accepts external connections, including vendor and contractor access.
- Bypass paths: Confirm whether split tunnels, legacy clients or local accounts can skip the second factor.
- Token type: Record which factor each entry point uses, since push and OTP are weaker against phishing than phishing-resistant options.
- Failover: Document what happens when the MFA service is unreachable, because a fail-open setting changes the control result.
- Logs: Confirm that authentication successes and failures are forwarded to the logging platform.
Before ordering the rollout, check that the system description names each boundary entry point and the authentication method it uses.
The identity provider and the administrative consoles that manage it come second, but they are often the highest-impact targets. Whoever controls the identity provider can create accounts, change policies and reset factors for every other system. Because of that, auditors treat MFA on administrator logins to the identity platform as a core expectation, even when the workforce login flow already requires a second factor.
- Admin consoles: Include the realm, tenant or directory administration interfaces of Keycloak, FreeIPA, ZITADEL or whichever platform is in scope.
- Factor reset rights: Identify who can enroll, unenroll or reset another user's second factor, and require MFA for those actions.
- Service accounts: Document which bind or API accounts exist and whether they are excluded from interactive MFA.
- Configuration changes: Log changes to authentication flows, required actions and policies.
- Upgrades: Record the version in use and who approves updates, since platform upgrades can change authentication behavior.
Confirm in the system description whether the identity platform is in scope as a system or only as a dependency of other systems, because auditors expect it to be described either way.
Administrative access to servers and SSH rank high because a single privileged session can change configuration, read data and disable logging. CC6.6 and the related logical access criteria make privileged paths a common focus in testing, so these systems usually need MFA on administrator accounts before standard user accounts are addressed. Sudo escalation and console access should be considered alongside the initial SSH login.
- Privileged accounts: Enumerate root, sudo-capable and break-glass accounts, and confirm each one requires a second factor.
- Jump hosts and bastions: Confirm that interactive access passes through a controlled entry point with MFA enforced.
- Automation exceptions: List service accounts and deployment pipelines that cannot answer an MFA prompt, and document how their credentials are protected.
- Consistency: Check that the same policy applies across the fleet, not only to hosts that were configured first.
- Session records: Confirm which login events and privilege escalations are logged and retained.
Before ordering the rollout, compare the system description's list of production hosts against the hosts actually enrolled, because gaps between those lists are a frequent audit finding.
Applications that hold customer data form the last tier. Their exposure is real but often mediated by the identity provider, so MFA is usually enforced once at single sign-on rather than separately in each application. The scoping question is whether each application that stores or processes in-scope data is actually federated through that identity provider, and whether any of them keep local logins that bypass it.
- Federation coverage: Map each in-scope application to its SAML or OIDC connection, and list any that do not use single sign-on.
- Local accounts: Identify applications with built-in passwords, shared accounts or API keys that skip the identity provider.
- Customer data: Mark which applications store or process data covered by the commitments in the description.
- Third-party SaaS: Confirm which vendor-hosted applications enforce their own MFA and which rely on your identity provider.
- Access reviews: Note whether application access is reviewed on a schedule, since that connects MFA coverage to who can reach the data.
Confirm with the application owners which logins are federated before the rollout order is fixed, because an application outside single sign-on needs its own MFA plan.
Which open source platforms fit a SOC 2 MFA design
Four platforms cover most SOC 2 MFA designs, but each covers a different set of logins. The right choice depends on where your users authenticate, which systems fall under CC6, and whether your team can operate the platform for a full Type 2 period. Use the cards to match each option to the systems in your scope.
privacyIDEA for second factors
privacyIDEA is the MFA engine in this set, not a full identity provider. It supports FIDO2 and WebAuthn passkeys, PIV and x509 smartcards, push, TOTP and HOTP, and it reads users from existing stores through LDAP, SQL, SCIM and HTTP resolvers. It integrates with a Linux PAM module, a Windows credential provider, Keycloak, and VPNs through RADIUS, which makes it a common choice when VPN, server logon and admin access must share one factor policy. Check which token types your users will accept and whether push requires the privacyIDEA Authenticator app. Licensed under AGPLv3.
Keycloak for SSO-protected apps
Keycloak is an identity provider that supports OpenID Connect, OAuth 2.0 and SAML 2.0, so MFA can be enforced once for web applications that sign in through it. It is licensed under Apache-2.0 and is a CNCF incubation project. For production, the supported databases include PostgreSQL 14 to 18, MariaDB, MySQL, Oracle, Microsoft SQL Server and Azure SQL, and the high availability design needs a synchronously replicated database. Confirm the database and cluster design before you commit, since the project ships four minor releases a year.
FreeIPA for Linux and SSH identity
FreeIPA combines a directory, Kerberos and certificate authority for Linux estates, and it can apply OTP to SSH and sudo logins from a central policy. It fits organizations whose evidence for CC6 centers on server access rather than web applications. Confirm that the OTP options and integrations you need are available in the release you deploy, and check how FreeIPA will coexist with any Active Directory forest already in place. Because it is a full identity stack, it adds more components for your team to run than a single MFA engine.
ZITADEL for passkeys and AGPL terms
ZITADEL covers SSO, MFA, passkeys through FIDO2 and WebAuthn, SAML 2.0, OpenID Connect and SCIM in one platform. It is licensed under AGPL-3.0, which requires legal review if you modify the software and make it available to users over a network. Its strongest fit is an organization that wants passkeys as the primary factor for a new set of applications. Check whether your SOC 2 scope already relies on a directory that ZITADEL must federate with, and confirm the support terms you need for the operating period.
Choose by scope and team capacity
Most designs combine two of these components rather than picking one. A common split is an identity provider for web applications, an MFA engine for VPN and server logon, and a directory for user records. The team that operates these services must produce change records, backup evidence and access reviews across the Type 2 period, so the operating load matters as much as the feature list. Ask each candidate partner which components they have run in production and how they would document configuration changes.
How to roll MFA out so it is operating for the whole Type 2 period
The sequence agrees scope with the auditor, puts MFA on the highest-exposure entry points first, and leaves a documented, stable configuration with complete logs before the observation window opens. The result is evidence that MFA ran as described for every day of the period, not just on the day of the audit.
Confirm system scope and MFA boundaries with the auditor
Before any rollout work, agree with your SOC 2 auditor which systems, user populations and access paths form the system description, and which of them the CC6 logical access controls must cover. Record which entry points are in scope, including VPN, workforce single sign-on, Windows and Linux logins, SSH, privileged accounts and externally reachable web applications, along with the owner of each. This step is done when the scope list is signed off by management and the auditor has confirmed in writing that it matches the system description draft. Ask the auditor how they expect to test the CC6.6 points of focus so the evidence you collect matches their test approach.
Enforce MFA on the highest-exposure entry points first
Switch on the second factor for the access paths that face the internet or grant the most privilege, usually remote access through the VPN, administrator and SSH access, and externally exposed applications. Use the platform's own policy controls, such as privacyIDEA policies or Keycloak authentication flows, so enforcement is central rather than configured per server. Keep a short, named list of any service or automation accounts that cannot complete an interactive second factor and review that list before go-live. This step is done when a test login to each prioritized entry point is challenged for a second factor and a failed attempt without a second factor is refused.
Enroll users and document every exception
Enroll the in-scope user population in waves, starting with administrators, and verify each enrollment against the directory record that the platform reads from. Make recovery and help desk verification steps explicit, because a reset performed outside a documented procedure becomes an exception that the auditor will ask about. Record each exception with the account, the reason, the compensating control, the approver and an expiry or review date. This step is done when every in-scope user is either enrolled or listed in the exception register with an approval on file, and the enrollment count reconciles to the directory.
Enable authentication and administrative logging
Turn on logging for authentication events, policy changes, token enrollments, token resets and administrator actions on the MFA platform, and forward those logs to the central log store your organization uses for monitoring. Confirm which fields are retained, such as timestamp, user, entry point, factor type, result and the identity of the administrator who changed a policy. Set retention to match your own record policy and confirm that logs cannot be edited by the administrators whose actions they record. This step is done when a test login and a test policy change both appear in the central store with the expected fields.
Configure alerting for MFA failures and policy changes
Define alerts for conditions that matter to the control, such as repeated failed second-factor attempts, token resets outside the help desk procedure, disabled policies and changes to the set of exempt accounts. Route the alerts to the team that reviews them and record who reviews them and how a review is evidenced, such as a ticket or a signed log review. Test each alert once with a controlled event so you know it fires. This step is done when each alert has a named owner, a test record and a documented review method.
Freeze the configuration and baseline the change process
Export the current policy, realm or flow configuration and the exception register as a baseline, and store that baseline under version control or your change management system. Any later change to MFA policy must go through your normal change process with a ticket, an approver and a note of the reason, because the Type 2 opinion covers operating effectiveness over the whole period. Confirm that platform upgrades are scheduled outside the observation window or documented as changes within it, and that the upgrade process includes a regression test of the MFA entry points. This step is done when the baseline is stored, the change process applies to MFA settings, and the owner of each upgrade decision is named.
Run a stable operating period and collect evidence
Operate the MFA controls without material change for a period before the observation window starts, so that the team can test the logs, alerts, exception reviews and change approvals in normal use and fix gaps while they are still cheap to fix. Collect evidence continuously: configuration exports, enrollment reconciliations, exception reviews, alert records and change tickets, filed by control and by month. Ask your auditor which samples they will draw from this evidence and make sure each sample can be retrieved without manual reconstruction. This step is done when a dry run of the evidence request produces every item from the stored records within a short working session.
Configuration evidence auditors ask for in a Type 2 period
This table lists the configuration and operating evidence a SOC 2 Type 2 examination typically samples for self-hosted MFA, the component that produces each item and what to confirm with the auditor. Read it as a starting inventory, since the auditor's sample selection and the exact population they test decide what you must produce.
| Evidence type | Produced by | What to keep and confirm |
|---|---|---|
| MFA policy export per application | privacyIDEA policy configuration, Keycloak realm and authentication flow settings, FreeIPA OTP and host policies | Dated exports showing which applications require a second factor, with change history. Confirm with the auditor how they want policies captured across the period. |
| Enrollment and token inventory reports | privacyIDEA token list, Keycloak credential records, FreeIPA user OTP data | Point-in-time inventories of enrolled tokens per user, with token type and status. Confirm whether they will sample individual users and request enrollment approvals for each. |
| Exception and break-glass approvals | Ticketing system records, linked to privacyIDEA policy or account changes | Approved, time-bound exceptions with owner, reason and expiry date. Confirm how the auditor expects to test that exceptions were reviewed and closed. |
| Change records for policy and platform upgrades | Change management tickets, Keycloak and privacyIDEA release notes applied, deployment logs | Records of who approved each upgrade or policy change and when it was tested. Confirm the auditor's expectations for emergency changes. |
| Authentication and failure logs forwarded to the SIEM | privacyIDEA audit log, Keycloak admin and login events, FreeIPA and host authentication logs | Evidence that logs are retained and forwarded, plus samples of failed and successful MFA events. Confirm the retention period and the log samples the auditor will request. |
| Access review records | Ticketing system and the identity source of record, with MFA enrollment status included | Periodic reviews showing that accounts without MFA were identified and resolved. Confirm the review frequency and population the auditor will accept. |
How upgrades and high availability affect the evidence trail
Upgrades to the MFA platform are changes that auditors will sample under CC8, so the change process for Keycloak or privacyIDEA needs to be written down before the Type 2 period starts. Keycloak plans four minor releases a year and a major release every two to three years, and says breaking changes in a minor release will be opt-in, which lowers the risk of a surprise behavior change. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Choose that mode deliberately, record who approves each upgrade, and keep the ticket, the release notes reviewed, the test results on a staging realm and the rollback plan together. Confirm with your partner how schema migrations run, since Keycloak migrates the database automatically at startup by default and also supports manual migration, which its upgrading guide suggests for large deployments.
Authentication availability is part of the same evidence trail. Keycloak documents three high availability architectures: a single cluster optionally spread across availability zones, multi-cluster deployments (v2) without external Infinispan, and the deprecated multi-cluster v1 design that used a separate Infinispan cluster per site. Both supported designs require a synchronously replicated database, so the database topology, replication mode and failover behavior are part of the MFA control, not only an infrastructure detail. Ask your partner to show which design is in use, how a failed node or site is detected, and how a database failover was tested. Confirm the supported database versions against the Keycloak database guide before you commit to a design.
The database and clustering design must be documented as part of the system description, because the auditor will test the controls against the system as described. Record the Keycloak version, the database product and version, the cluster topology, the upgrade approval workflow and any manual migration steps in the system description and in the change log. If an upgrade or topology change happens during the Type 2 period, the description should show when it occurred and what changed. Keep metrics and health checks from the platform, such as the Keycloak metrics endpoint, as operating evidence that authentication was available during the period.
What MFA tooling alone does not satisfy in SOC 2
A self-hosted MFA platform enforces a control, but SOC 2 examines whether the surrounding control environment works over a period. The cards below cover the gaps that auditors typically test alongside MFA, and who is responsible for closing each one.
Written policies and risk assessment
CC6.6 expects logical access measures tied to a defined boundary and threat picture, so MFA needs a written authentication policy and a risk assessment that names which systems, user groups and remote paths it covers. Confirm who approves the policy, how often it is reviewed, and whether exceptions such as service accounts are described in it. The 2017 TSC treats points of focus as design aids rather than separate requirements, so document how each chosen point of focus is addressed.
Access reviews tied to HR records
MFA only protects accounts that exist in the right place. Auditors commonly sample user access reviews and check that terminated staff and movers lost enrollments and application access on time. Confirm that the MFA user store is fed from or reconciled against the HR system of record, and that each review produces a dated list of enrolled tokens, who approved it and what was removed. Revoked tokens and disabled users should appear in the evidence.
Monitoring and review of MFA exceptions
Every bypass, disabled factor, emergency code issued and help desk reset is a control event. Management needs a defined process to review these exceptions, with a named reviewer, a cadence and a record of approval for each one. Confirm that the MFA platform logs enrollment, authentication failures, policy changes and administrative actions, and that those logs are forwarded to central monitoring where they can be retained and examined.
Vendor and hosted component controls
A self-hosted MFA stack still depends on third parties: the operating system and database vendors, the SMS or email gateway, cloud hosting, and any managed support contract. Each of these needs a current inventory, a review of its security commitments, and a record of how changes are approved. If push notifications or SMS depend on an external service, that dependency belongs in the vendor review, and the team should confirm where authentication data is processed.
Configuration and change evidence
A Type 2 report covers operating effectiveness over a period, so the team must show that MFA settings did not drift. Keep exported configuration baselines, change tickets for policy edits, and records of software upgrades to the MFA server and its identity provider. Keycloak documents that operator updates can upgrade unintentionally unless manual approval is set, so confirm which update mode is in use and how approvals are recorded.
Division of responsibilities with the auditor
DeployOpen plans, configures, documents and supports the MFA deployment, and can prepare the controls and evidence described above for an assessment. It does not issue SOC 2 reports, attestations or certifications. An independent CPA firm performs the examination and forms the opinion, and the organization's management provides the written representations. Ask any implementation partner to confirm this split in writing before work starts, and agree the evidence list with the auditor early.
Questions buyers ask before hiring help for SOC 2 MFA
Does SOC 2 require multi-factor authentication by name?
No. SOC 2 does not name MFA as a requirement. The AICPA's 2017 Trust Services Criteria place logical access under the common criteria in CC6, and CC6.6 asks the organization to restrict access, protect authentication credentials, require additional authentication or credentials, and protect its boundaries against threats from outside the system. Points of focus under that criterion include requiring additional credentials, which is where MFA usually appears in practice. Auditors test the controls you describe, so the question is whether your own control design and evidence show MFA covering the systems in scope. Confirm the exact wording of your control matrix with your auditor before the examination window opens.
What drives the cost and effort of a self-hosted MFA rollout for SOC 2?
Cost follows the components and the number of systems you connect. The main cost lines are servers and high availability for the MFA service, the token types you choose (software TOTP, push, FIDO2 keys or smartcards), integration work for each system such as VPN, Windows, Linux PAM, SSO and admin consoles, enrollment and help desk effort for every user, and the support subscription or retainer that keeps the platform patched. Initial build is largely one-time. Enrollment, help desk and patching recur. Ask any partner for a quote that lists each integration, the user count, the token mix, the high availability design and the recurring support terms separately. DeployOpen does not publish a price list; quotes follow written scope.
How long does a self-hosted MFA rollout take, and what sets the timeline?
No duration can be stated here without a written scope. The timeline depends on how many systems must be covered, whether each integration is standard or needs custom work, how many users must enroll and in what order, and whether a change window is required for production logins. Scope that includes privileged accounts first, then remote access and externally exposed applications, usually takes longer than a single pilot group. Ask for a phased plan with dated milestones, the acceptance tests for each phase and the dependencies on your identity directory and change process. Confirm these items in the signed scope before work starts.
What does the rollout need from our own staff?
Expect your staff to provide decisions and access, not just approvals. Your side typically supplies a directory owner for user data, network and firewall owners for the MFA servers, administrators for each integrated system such as VPN, SSO and Windows or Linux fleets, a help desk lead who will handle enrollment and lockouts, and a control owner who will collect evidence during the Type 2 period. Identify these people before scoping, because delays in access approval are a common source of schedule slip. Ask the partner to name the client-side roles and the hours they require in the written scope.
Can our internal team run a self-hosted MFA platform without a partner?
Yes, if the team has the skills and capacity. Running an MFA service is an operations job: it needs people who can maintain the servers and database, apply upgrades, manage high availability, handle token enrollment and recovery, and produce logs for auditors. The open-source components are maintained by their projects, and vendor release notes must be reviewed and tested before updates reach production. Many teams split the work, using a partner for the initial build and integrations and keeping operations in-house, or contracting ongoing support as a retainer. Assess your team against the operational tasks in a written plan before deciding.
Can a partner make the SOC 2 audit pass?
No partner can guarantee an audit result. An independent CPA firm issues the SOC 2 report, and the outcome depends on the controls your organization designs, operates and evidences over the examination period. A partner can implement and configure self-hosted MFA, document the configuration, set up logging and prepare the evidence your control owner needs. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Ask any partner to show how their deliverables map to your control matrix, and confirm with your auditor which evidence they will sample.
What configuration evidence should we keep for a Type 2 period?
Keep evidence that shows MFA was configured, enforced and operating across the whole observation window. This includes the written MFA policy and the list of in-scope systems, configuration exports showing which applications require a second factor, records of enrollment and token assignment, change tickets for policy and version updates, and logs of authentication events and exceptions. Also keep records of access reviews for MFA exemptions, especially service accounts. Confirm the sampling approach, retention period and format with your auditor before the period begins, since evidence gathered late is hard to reconstruct.
How DeployOpen scopes and delivers SOC 2 MFA evidence
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted MFA inside the client's own cloud accounts, data centers or air-gapped networks. Work starts from a fixed scope agreed in writing, which names the systems in the boundary (for example, VPN, SSO-integrated web apps, Windows and Linux logins and administrative access), the token types, the user stores and the deliverables. Scope is the first control decision: it determines which CC6 controls the MFA platform supports and which evidence the auditor will request. Clients should expect the scope document to list the systems in and out of the boundary and to state who owns enrollment, recovery and the help desk process.
During delivery, DeployOpen configures the MFA components, such as privacyIDEA, Keycloak or FreeIPA, to the agreed policies, integrates them with the in-scope systems, applies hardening settings, and writes the operating procedures. Documentation typically covers the system description inputs, the configuration baseline, enrollment and recovery runbooks, and the logs that show authentication decisions. DeployOpen prepares these controls and evidence for the assessment, but it does not issue audit reports, attestations or certifications. Your independent SOC 2 auditor decides whether the controls meet the Trust Services Criteria, and your management's system description remains the source of truth for what is in scope.
After go-live, ongoing support, upgrades and continuous testing are available as retainers, which matter because a Type 2 period runs across routine changes such as component upgrades, new applications and staff turnover. Ask for a written list of the change-control steps that will be applied to MFA configuration and for the evidence each change produces. Confirm with your auditor which samples they will pull and which records they will accept, and ask DeployOpen to show how those records are generated and retained before the observation window opens.
