SSO, 2FA, and MFA by Industry: What’s Actually Required (and Why)

“Best practice” and “legal requirement” get used interchangeably in security conversations, and they shouldn’t be. Some industries are genuinely mandated to use MFA by name, with specific technical requirements attached. Others get strongly pushed toward it through data-protection obligations that never actually say the word “authentication.” Knowing which situation you’re in changes both your compliance exposure and your actual rollout priorities.

Here’s the accurate breakdown, industry by industry, with the regulations named directly rather than the vague “compliance requires strong security” framing most comparison posts default to.

Quick Reference

Payment Card Processing: The Clearest Mandate on This List

If your organization stores, processes, or transmits cardholder data, PCI DSS 4.0.1 doesn’t leave room for interpretation. As of the March 31, 2025 compliance deadline, MFA is required for essentially all access into the cardholder data environment, not just remote or administrative access the way earlier versions specified. The standard spells out three specific requirements: MFA for all non-console administrative access (8.4.1), MFA for all access into the environment generally (8.4.2), and MFA for all remote access originating outside the organization’s network, including third-party and vendor access (8.4.3).

PCI SSC also added a configuration requirement that trips people up: authentication factors have to be evaluated independently, and the system can’t reveal which factor failed if login is denied. A login flow that checks the password first and only asks for the second factor if the password was correct no longer satisfies the standard on its own, because that flow inadvertently confirms whether the password was right before the second factor is even entered.

What this looks like in practice: a retailer’s point-of-sale support team needs MFA to remotely access the systems that process transactions, not just to log into the corporate email. A payment processor’s engineers need MFA on every environment that touches cardholder data, cloud or on-premises, with no exceptions carved out for internal-only systems.

Healthcare: More Nuanced Than Most Coverage Suggests

This is where a lot of blog content gets sloppy. It’s common to see “HIPAA requires MFA” stated flatly, and it’s not quite accurate yet. As of this writing, HHS has issued a Notice of Proposed Rulemaking that would make MFA mandatory for all systems creating, receiving, maintaining, or transmitting electronic protected health information, removing the current “addressable” classification that let organizations treat authentication controls as optional if they documented a reason. That NPRM has not been finalized. It’s been through public comment, drawn organized pushback from hospital groups over implementation timelines and cost, and the current federal timeline target has slipped further out.

What that means practically: MFA isn’t yet a black-letter HIPAA requirement the way it is under PCI DSS, but it is where enforcement is heading, and auditors already treat it as a baseline “reasonable and appropriate” safeguard in practice, proposed rule or not. Organizations waiting for the rule to finalize before acting are optimizing for the wrong risk.

What this looks like in practice, and why it’s genuinely harder here than in most industries: clinicians move between workstations dozens of times per shift, often with gloved hands that make fingerprint scanning unreliable and PPE that interferes with facial recognition. A 30-second authentication delay isn’t just an inconvenience the way it might be in an office environment, it’s friction sitting directly between a clinician and patient care. This is a large part of why healthcare environments lean on badge-tap-plus-PIN authentication paired with SSO across clinical systems (Epic, Cerner, and similar platforms), with step-up MFA reserved specifically for higher-risk actions like exporting large data sets or accessing records from an unusual location, rather than applying the same friction to every single login.

Banking and Financial Services: Guidance, Not a Single Named Rule

Unlike PCI DSS, there isn’t one specific banking regulation that says “implement MFA” in those exact words for every financial institution. What exists instead is FFIEC supervisory guidance, updated most recently in 2021, which examiners use to assess whether a bank’s authentication and access controls are adequate. The guidance explicitly calls out the weaknesses of single-factor authentication, recommends layered security, and requires institutions to risk-assess authentication needs across customers, employees, and third parties, not just customer-facing logins.

In practice, this functions as a mandate even without being phrased as a strict rule, because failing an FFIEC examination on authentication controls carries real regulatory consequences. Banks that treat the guidance as optional tend to find out otherwise during their next exam cycle.

What this looks like in practice: step-up authentication triggered specifically by high-risk actions, a large wire transfer, a new payee added, a login from an unrecognized device, rather than uniform friction on every session. This is also where SSO and MFA most visibly work together: employees use SSO to move between the dozen internal systems a bank typically runs (core banking platform, CRM, transaction monitoring, compliance tooling), with MFA protecting the identity provider account all of that access flows through.

If your organization operates in the EU or serves EU customers, the equivalent named mandate is PSD2’s Strong Customer Authentication requirement, which explicitly requires two independent factors for most electronic payment transactions, a more direct parallel to PCI DSS than anything in the US banking framework.

Higher Education: Pushed Toward MFA Without Being Told To Use It By Name

FERPA protects the privacy of student education records, but it doesn’t specify authentication mechanisms the way PCI DSS or the proposed HIPAA update do. There’s no line in FERPA that says “implement multi-factor authentication.” What FERPA does require is that institutions maintain reasonable safeguards against unauthorized access to education records, and as breaches and credential-stuffing attacks against student portals have increased, “reasonable” has effectively come to mean MFA in the eyes of most university IT security offices, even without a regulatory citation forcing the point.

What this looks like in practice: a single SSO login granting students access to their course materials, grades, and email, since forcing students to separately authenticate into a dozen disconnected systems (the LMS, the registrar’s portal, campus email, library resources) creates exactly the kind of password fatigue that leads to weak or reused credentials. Faculty and staff typically get a stricter policy layered on top, since their accounts touch more sensitive records (grades, financial aid data, sometimes health records through student health services) than a student’s own login does.

Government and Public Sector: The Strictest Tier

Federal agencies and their contractors operate under NIST’s authentication assurance level framework (NIST SP 800-63), and contractors handling federal contract information specifically fall under NIST SP 800-171. Under this model, MFA isn’t a binary yes-or-no requirement, it scales with the assessed risk of the system. Low-risk systems may only recommend MFA; moderate-risk systems require it; high-risk systems require MFA using a hardware-based authenticator specifically, not just any two factors.

What this looks like in practice: federal employees and many contractors authenticate using PIV or CAC smart cards, a possession factor combined with a PIN, rather than the password-plus-app pattern common in the private sector. This isn’t a stylistic choice, it reflects the higher assurance level the framework requires for government systems compared to a typical enterprise login.

The Pattern Across All of This

Notice what’s consistent across every industry above: none of them treat SSO as a substitute for MFA, and none of them treat MFA as a substitute for controlling how many systems a single login can reach. The regulations differ in how explicitly they name authentication requirements, but every framework here either mandates or strongly implies the same underlying architecture, convenient access through SSO, strong identity verification through MFA, applied more strictly to whatever data in that industry is considered highest-risk. For the deeper mechanics of how SSO and MFA fit together as a combined architecture rather than competing choices, see SSO vs 2FA vs MFA: The Real Differences, Pros, Cons, and Which One You Actually Need. For the broader case on MFA specifically, including where it fails in practice, see Multi-Factor Authentication for Business in 2026. If your organization is specifically in healthcare or government and needs to see how MFA fits into a full identity management strategy, Integrated Enterprise Security Solutions: IAM, MFA, SSO, and Beyond covers the fuller architecture.

Whichever regulation your industry actually answers to, the underlying setup you need is the same one covered above: SSO for convenient access, MFA protecting the account that access flows through, applied more strictly wherever your highest risk data actually sits. OmniDefend combines single sign on, multi factor authentication, and biometric verification in one platform built for regulated environments like banking, healthcare, and government. Start a 30 day free trial and see how it maps onto your specific compliance requirements. 

FAQs

1. Does HIPAA legally require MFA right now? 

Not yet, as a finalized rule. HHS has proposed making it mandatory through a Notice of Proposed Rulemaking, but that rule hasn’t been finalized, and the federal timeline has continued slipping. Auditors and examiners already treat MFA as a baseline expectation in practice, so waiting for the rule to finalize before implementing it is not a defensible compliance strategy.

2. Is MFA required for all banks, or just certain ones? 

There’s no single named rule requiring it universally, but FFIEC supervisory guidance functions as a de facto requirement for any US financial institution subject to federal examination, since inadequate authentication controls are a standard examination finding.

3. Does FERPA require schools to use MFA? 

No, not by name. FERPA requires reasonable safeguards for student data, and MFA has become the practical standard institutions use to meet that bar, but the regulation itself doesn’t specify authentication technology.

4. Why do PCI DSS and PSD2 name MFA specifically while HIPAA and FERPA don’t? 

Largely because of how each framework was written and by whom. PCI DSS is written and maintained by a payment industry council specifically focused on technical security controls, so it can be prescriptive about authentication mechanics. HIPAA and FERPA are broader privacy statutes written to cover a wide range of safeguards, not just authentication, which is part of why they tend to specify outcomes (“reasonable safeguards”) rather than specific technical controls.

5. If my industry doesn’t explicitly require MFA, is it still worth implementing? 

Yes. Regulatory silence isn’t the same as low risk. Credential-based attacks don’t check which industry they’re targeting before they work, and “our regulator doesn’t technically require it” is a weak position to be in after a breach, regardless of what the letter of the law says at the time.

Sources

• PCI Security Standards Council, Updated PCI DSS v4.0 Timeline
• PCI Security Standards Council, PCI DSS v4.0 Standard
• U.S. Department of Health and Human Services, HIPAA Security Rule NPRM Fact Sheet
• Federal Financial Institutions Examination Council, FFIEC Issues Guidance on Authentication and Access to Financial Institution Services and Systems
• NIST, Multi-Factor Authentication guidance for small business