Credential-based attacks are the leading cause of data breaches, and in the majority of post-incident investigations, the finding is the same: no second factor was required. For SMBs in healthcare, SaaS, technology, and defense contracting, that gap is not just a security problem. It is a compliance failure with direct consequences, including audit findings, regulatory fines, and in some cases personal liability for executives. MFA requirements now appear across every major framework, yet many organizations still treat them as optional, or conflate them with Single Sign-On, which serves a different purpose. Understanding what each framework demands, where enforcement applies, how SSO fits in, and what gaps cost in practice is worth doing before the next audit cycle.
What MFA Actually Does (and Why It Matters)
Multi-Factor Authentication requires users to verify their identity through at least two independent factors before gaining access. Typically this means something they know (a password), combined with something they have (a one-time code from an authenticator app or a hardware token) or something they are (biometric verification).
The practical impact is significant. According to Microsoft's internal data and various industry studies, MFA blocks more than 99% of automated credential-stuffing attacks and over 90% of targeted account compromises. Passwords alone are not reliable. They get reused across services, captured in phishing campaigns, and sold in bulk after data breaches. Adding a second factor means a stolen password is far less useful to an attacker.
For compliance purposes, MFA is no longer considered a nice-to-have enhancement. Across every major framework relevant to SMBs in healthcare, technology, and defense, it is treated as a baseline control. The question is not whether to implement it, but how thoroughly.
MFA Requirements Across Major Compliance Frameworks
Each framework has its own language, but the underlying requirement is consistent: protect privileged and sensitive system access with more than just a password.
Where MFA and SSO Enforcement Must Be Applied
Frameworks tend to be principles-based rather than prescriptive, so they do not specify every system that requires MFA. Auditors and assessors consistently focus on the following areas:
HIGH-PRIORITY MFA ENFORCEMENT AREAS
- All administrative and privileged accounts, including local admin accounts on servers and workstations
- Remote access connections, including VPN, RDP, and any remote management tools
- Cloud applications that store or process sensitive data (SaaS tools, cloud infrastructure consoles)
- Email platforms, which are the most common entry point for phishing and business email compromise
- Any system storing or transmitting regulated data (ePHI, cardholder data, CUI)
- Developer access to production environments and code repositories
A SaaS company going through SOC 2 can expect auditors to verify MFA enforcement across cloud infrastructure, not just a policy document that recommends it. For DoD contractors working toward CMMC Level 2, MFA on privileged accounts is treated as a non-negotiable assessed practice under that framework. Gaps in both cases will generate findings that delay or block certification.
What About SSO? Is That Required Too?
Single Sign-On is not directly required by any of the major frameworks listed above, but that framing understates its practical value for compliance purposes.
SSO allows users to authenticate once through a central identity provider, like Okta, Azure AD, or Google Workspace, and then access multiple applications without logging in separately to each one. From a compliance standpoint, this centralization matters for a few reasons.
Centralized MFA Enforcement
Without SSO, enforcing MFA consistently across dozens of applications is an operational challenge. Each application has its own authentication settings, and a single misconfigured app can become a gap in controls. With SSO, MFA policy is set once at the identity provider level and applies uniformly across all connected applications. When an auditor asks how MFA is enforced organization-wide, "through our identity provider" is a much cleaner answer than "we configure it separately in each tool." This is where SSO and MFA enforcement intersect most directly for compliance purposes.
Simpler Access Reviews
SOC 2 and many other frameworks require periodic access reviews to verify that only the right people have access to the right systems. With SSO, identities are managed in one place, giving administrators a full picture of what each user can access. Without it, access reports must be pulled from five or ten different systems and reconciled manually. SSO does not eliminate the need for access reviews, but it makes them significantly more manageable.
The SSO Risk That Often Goes Unmentioned
SSO also introduces a meaningful concentration risk. If an SSO account is compromised, especially one with administrative privileges in the identity provider, an attacker potentially has access to everything that account can reach. This is sometimes called a "keys to the kingdom" scenario. It is not a reason to avoid SSO, but it is a reason to treat SSO admin accounts with the highest level of scrutiny. Hardware security keys or phishing-resistant authentication methods like FIDO2 are worth considering for those accounts specifically.
Important consideration: SSO consolidates authentication risk into a single control point. A compromised identity provider admin account can expose every connected system simultaneously. The strongest available authentication controls belong on those accounts.
The Real Cost of Skipping MFA
Beyond compliance, the operational consequences of missing MFA are well-documented. Credential-based attacks are the most common initial access vector in data breaches, and they are disproportionately effective against organizations that have not enforced a second factor.
From a compliance standpoint, skipping MFA can mean:
COMPLIANCE RISKS
- Audit findings that delay or block SOC 2 attestation or CMMC certification
- PCI DSS non-compliance findings that can result in fines from card brands or acquiring banks
- HIPAA enforcement actions if a breach occurs and MFA was not implemented despite a risk analysis flagging the gap
- Potential personal liability for executives and security officers in some regulatory contexts
For California-based businesses, there is additional context. The CCPA and its amendment, CPRA, do not explicitly require MFA, but they require reasonable security measures. Regulators and courts have used frameworks like the CIS Controls and NIST as benchmarks for what constitutes reasonable protection, and both include MFA as a foundational control. An organization that suffers a breach without MFA in place faces a harder argument that it took adequate precautions.
Getting MFA Implementation Right
Implementing MFA is not especially complicated, but it requires thoughtful planning to avoid gaps or user friction that leads to workarounds.
A practical approach: start with identifying all systems that access sensitive or regulated data. Prioritize admin accounts and remote access first, since those are the highest-risk entry points and the areas auditors scrutinize most closely, then work outward to all user-facing applications.
For authentication methods, time-based one-time passwords (TOTP) from an authenticator app are a reasonable baseline for most users. Push notifications from apps like Duo or Microsoft Authenticator add convenience. For high-privilege accounts, phishing-resistant options like FIDO2 hardware keys offer stronger protection and are increasingly expected in CMMC and FedRAMP contexts.
Policies should be documented, in-scope systems tracked, and exceptions reviewed on a regular cycle. Auditors ask for evidence that MFA is enforced, not just enabled. A policy that states MFA is required, without technical enforcement to back it up, is unlikely to satisfy a thorough assessor.
The Bottom Line
MFA requirements are now embedded in every major compliance framework relevant to SMBs in healthcare, technology, SaaS, and defense contracting. Whether the goal is SOC 2 attestation, PCI DSS compliance, satisfying HIPAA MFA requirements under the Security Rule, or CMMC certification, MFA is a baseline expectation, not an advanced control.
No framework explicitly lists SSO requirements, but for most organizations managing more than a handful of applications, SSO is the most practical way to enforce authentication policy consistently.It makes MFA enforcement more consistent, access management more tractable, and compliance monitoring considerably simpler.
The question is no longer whether to implement these controls. It is whether current implementation is thorough enough to hold up under audit, and whether the right expertise is in place to get it done correctly.
Ready to Be Audit-Ready?
Planet 9 is a Bay Area cybersecurity consulting firm specializing in SOC 2 readiness for SMBs in healthcare, SaaS, and technology. Our vCISOs and compliance managers help you choose the right approach, configure GRC tools if needed, and get audit-ready without wasted time.
