SOX and MFA: What the Law Doesn't Say, What Auditors Test Anyway, and How to Close the Gap

Search the Sarbanes-Oxley Act for "multi-factor authentication" and you will find nothing. SOX predates modern MFA entirely. It is a 2002 financial-reporting law, not a cybersecurity standard. And yet every audit season, companies get IT general control findings for missing MFA on financial systems. This post explains that gap honestly: where the requirement actually comes from, what auditors test, why the findings concentrate on ERP systems, and the fastest way to remediate before the next testing cycle.

Where the "requirement" actually comes from

SOX Section 404 requires management and the external auditor to assess internal control over financial reporting (ICFR). Because financial reporting runs on IT systems, that assessment includes IT general controls (ITGCs) - and the ITGC domain that matters here is access to programs and data: who can reach the systems that feed the financial statements, and how their identity is verified.

Neither SOX nor the SEC prescribes specific authentication technologies. Auditors evaluate ITGCs against control frameworks and against what a reasonable control environment looks like today. That last part is where MFA enters: authentication expectations are evaluated against current practice, and current practice has moved. A decade ago, complex passwords often satisfied a logical-access control. Today, password-only access to a SOX-scoped system - especially remote access or privileged access - is the kind of gap audit teams write up, because credential compromise is a common path to unauthorized changes in financial data.

The consequence ladder is what makes this concrete. An MFA gap can surface as an ITGC deficiency. Deficiencies that could permit unauthorized changes to financial data get evaluated for escalation to significant deficiency - which goes to the audit committee - or, combined with other control failures, contributes to a material weakness, which is publicly disclosed. "We will add MFA next year" reads very differently when the alternative is a paragraph in the 10-K.

What auditors actually test

In ITGC access testing for in-scope systems, expect some version of:

• Authentication mechanism review - how users prove identity to each in-scope application; whether MFA is enforced, for whom, and how exceptions are handled.
• Privileged access - administrators, superusers, and IT staff with change access; MFA on these accounts is usually the sharpest expectation.
• Remote access paths - any way into financial systems from outside the network.
• Evidence - not policy documents: configuration exports, screenshots of the enforced challenge, and authentication logs. Auditors test operation, not intention.
• Coverage completeness - and this is where the findings come from. The SaaS ERP behind Okta passes. The finding lands on the system the IdP never reached.

Why the findings concentrate on ERP systems

The systems in SOX scope are, by definition, the ones that produce the financial statements. At many companies, that means on-premises ERP: JD Edwards, Oracle E-Business Suite, PeopleSoft, SAP, and the homegrown applications feeding them. These are exactly the systems where MFA is hardest to add natively: no modern authentication support, vendor middleware as the official answer, and a change-control process that makes "modify the login flow" a next-fiscal-year conversation.

The SOX MFA gap is simple: the systems most in scope are the systems least able to do MFA natively.

The fast remediation path: enforce MFA in front, not inside

Datawiza Access Proxy adds MFA to SOX-scoped web applications at the access layer - no ERP code changes, no vendor middleware, and nothing installed on application servers.

• With your identity provider: Datawiza intercepts requests before the application's login page and redirects to Microsoft Entra ID, Okta, Ping, or Cisco Duo. The ERP joins the same MFA and conditional access policy as everything else, with SSO included. One policy, one evidence set, every in-scope app.
• With built-in MFA, no IdP required: users keep signing in with their existing application credentials, and Datawiza enforces the MFA challenge before application access. This is the fastest route when a finding has a remediation deadline and an identity project is not on the calendar.

Both modes produce the artifacts ITGC testing asks for: policy configuration, demonstrable challenge on each application, and per-application authentication logs.

The ERP specifics are covered in dedicated implementation guides: JD Edwards MFA, Oracle EBS SSO and MFA, and PeopleSoft MFA - each designed for fast rollout when the finding is dated and the retest is scheduled.

Preparing for ITGC access testing: a short checklist

1. Inventory in-scope applications - everything that initiates, records, processes, or reports financial data, including the legacy web apps upstream of the GL.
2. Map authentication per application - MFA status, enforcement point, and exceptions. "The VPN has MFA" does not answer the question for an auditor testing application-level access.
3. Close gaps at the access layer where applications cannot be modified - proxy in front, IdP mode or built-in MFA, pilot, cut over.
4. Assemble evidence per application - configuration, challenge demonstration, logs.
5. Document residual exceptions as remediation plans with dates - and expect diminishing auditor patience for the same exception two cycles running.

Frequently asked questions

Does SOX require MFA?

Not by name. The statute never mentions authentication technology. But SOX 404's ICFR assessment includes IT general controls over access to financial systems, and auditors evaluate authentication against current practice. In 2026, password-only access to in-scope systems - especially privileged or remote access - is routinely treated as an ITGC deficiency.

Which systems are in SOX scope for MFA?

Any system that initiates, records, processes, or reports financial data: the ERP and general ledger first, plus consolidation tools and upstream applications that feed them. Scope follows the financial data, not the technology's age.

What happens if an auditor finds missing MFA?

It is documented as an ITGC deficiency. Depending on severity and compensating controls, it can escalate to a significant deficiency reported to the audit committee or contribute to a material weakness that is publicly disclosed.

How do we add MFA to a legacy ERP before the next audit cycle?

Enforce it at the access layer: a proxy in front of the application adds MFA through your IdP with SSO, or via built-in MFA with existing logins unchanged. The ERP, its roles, and its change-control record stay untouched.

Is MFA on the VPN enough for SOX?

Usually not on its own. ITGC testing evaluates access to the in-scope application. A VPN challenge does not govern the internal user already on the network, and it produces network logs, not per-application evidence. Auditors increasingly expect the control at the application boundary.

The bottom line

SOX never says MFA - and that is why the topic confuses teams every audit season. The requirement is real but indirect: ITGC access controls, evaluated against current practice, on systems that mostly predate modern authentication. Enforcing MFA at the access layer closes the gap quickly, produces the evidence testing demands, and does not touch the ERP an auditor is also watching for change control.

If an ITGC finding or the fear of one names your ERP, book a demo - bring the system and the finding language, and we will walk through the remediation path.