Seven government cybersecurity agencies, FBI, CISA, the RCMP, Australia's ACSC and AFP, Canada's CCCS, and the UK's NCSC, updated a joint advisory on 29 July 2025 whose first recommended action is to enable and enforce phishing-resistant multi-factor authentication. California's finalized CCPA cybersecurity audit regulations, effective 1 January 2026, name the same thing as an authentication component auditors must assess. The MFA most companies actually run, a push notification you tap "Accept" on, is exactly the kind both documents warn does not qualify.
What the audit actually asks about authentication
The regulation's scope section is specific about this. Under Section 7123(c)(1)(A) of the CPPA's final text, the audit must assess "Multi-factor authentication (including multi-factor authentication that is resistant to phishing attacks for employees, independent contractors, and any other personnel, service providers, and contractors)." That is not boilerplate language borrowed from a generic security framework. It is one of eighteen components the audit can cover, and the regulation lets the auditor decide which apply to your information system, but authentication is near-certain to be in scope for any business processing enough personal information to trigger the audit requirement in the first place.
For a mid-market employer running an automated decision system over employment, credit, or housing data, the kind of business California's ADMT rules are aimed at, that scoping question answers itself. The system holding those decisions, and the accounts that can reach it, is precisely the kind of information system the audit exists to examine.
Why "we have MFA" doesn't survive as evidence
Section 7122(d) of the same regulation states that no audit finding "may rely primarily on assertions or attestations by the business's management." Findings have to rest on the auditor's own evidence: documents, sampling, testing, interviews. A slide that says "MFA enforced for all users" is an assertion. What the auditor tests is which authentication methods those users actually have enabled, and whether the ones with access to personal information sit on the weaker end of that list.
That distinction is the whole post. A company can have MFA enabled everywhere and still fail this component, because the regulation doesn't ask whether MFA exists. It asks whether the MFA is phishing-resistant, for the people who matter most.
The MFA hierarchy, strongest to weakest
CISA's own fact sheet on the subject, published October 2022, ranks the common forms of MFA from strongest to weakest against the attacks that actually break them:
| MFA form | Resistant to |
|---|---|
| FIDO/WebAuthn or PKI-based | Phishing, push bombing, SIM swap, SS7 |
| App or token OTP, or push with number matching | Push bombing, SS7, SIM swap (not phishing) |
| Push notification without number matching | SS7, SIM swap (not phishing or push bombing) |
| SMS or voice code | Nothing on this list |
CISA is blunt about where most organizations sit: "not all forms of MFA are equally secure," and it calls phishing-resistant MFA "the gold standard," with everything else acceptable only as a step on the way there. A plain push notification, the default on most identity platforms and the one your engineers tap without thinking, sits second from the bottom. It stops a stolen password from being enough on its own. It does nothing against a threat actor who can get a person to hit "Accept."
The advisory seven government agencies just updated
That gap isn't theoretical. The joint advisory those seven agencies updated in July 2025 tracks a group known as Scattered Spider, active since at least 2022 and, per the update, still running new ransomware variants as of June 2025. Its playbook barely touches malware. It calls IT help desks pretending to be an employee, gets a password reset, and either floods the real employee with MFA prompts until one gets accepted (what CISA calls MFA fatigue) or talks the help desk into moving that employee's MFA onto a device the attacker controls. Both moves work specifically because the MFA on the other end is a push prompt or an OTP, not a hardware key or a certificate.
The advisory's first listed mitigation, ahead of backups and application controls, is to "enable and enforce phishing-resistant multi-factor authentication," pointing readers straight at CISA's fact sheet above. Two different documents, from two different agencies, converging on the same specific fix is a stronger signal than either alone.
A worked example: the finding behind a green checkmark
Picture a 90-person mid-market employer running an applicant-scoring tool across its hourly hiring pipeline, the kind of automated decision the CCPA's ADMT rules cover starting January 2027. Its security dashboard shows MFA enforced for 100% of accounts, and its cybersecurity audit prep treats that number as done. The auditor asks a narrower question: which accounts can reach the scoring tool's decision logs, and what MFA do those specific accounts use? The answer turns out to be the same mobile push notification every other account in the company uses, because nobody had separated "MFA is on" from "MFA is the kind that survives a help-desk phone call." That gap, not the presence or absence of MFA, is what gets written up, and it is written up as a company-specific finding rather than a policy failure, because the policy already said MFA was required.
What this means for your team
Migrating every account to FIDO2 or WebAuthn overnight is neither realistic nor what CISA asks for. Its own fact sheet names app or token OTP, or push with number matching, as the right interim step for organizations that cannot move everywhere at once, and that is a defensible place to be mid-migration if you can show the auditor a plan and evidence of progress on it. What is not defensible is treating every account the same regardless of what it can reach. Start with the accounts that touch personal information or hold privileged access, the same accounts a decision log or an ADMT audit trail depends on, and get those onto a phishing-resistant method first. Everything else can follow on a slower clock.
This isn't the first problem to solve if your business hasn't yet worked out whether the cybersecurity audit requirement applies to it at all; that scoping question, and the deadline it sets once answered, is its own piece of homework, and it comes before an authentication upgrade, not after.
If you want a straight read on which of your accounts an auditor would flag under this specific component, tell us what your identity setup looks like and we'll tell you what would need to change before your first audit, the same evidence discipline our decision-logging guidance argues for on the ADMT side of these same regulations. If the system in question is the automated decision tool itself rather than the audit around it, that's a separate scoping conversation, and we're happy to have both.
Sources
- California Privacy Protection Agency: Text of Regulations, CCPA Updates, Cyber, Risk, ADMT, and Insurance Regulations, approved 22 September 2025, Sections 7120, 7122 and 7123
- CISA: Implementing Phishing-Resistant MFA, October 2022
- CISA, FBI, RCMP, ASD's ACSC, AFP, CCCS and NCSC-UK: Scattered Spider joint Cybersecurity Advisory AA23-320A, originally published 16 November 2023, updated 29 July 2025