MFA Exception Rationalizer (CISA CPG 1.1)

Compliance Security Critical Infrastructure CISA MFA FIDO2

Overview

Document the transition to phishing-resistant MFA and draft MFA-exception rationales for Critical Infrastructure. Identifies legacy systems that cannot support MFA, proposes compensating controls (e.g. jump hosts), and validates authentication hardware against the FIDO2 standard required by CPG 1.1.

Example Conversation

You: We’re preparing CPG 1.1 evidence for our water utility. I have an equipment list with our current and proposed auth methods. Can you check it against FIDO2 and help us document the legacy SCADA systems that can’t do MFA?

Agent: I’ll run fido2_compliance_check on your equipment list to flag what’s phishing-resistant vs. non-compliant or unknown. Then I’ll draft exception rationales for the SCADA HMIs using the skill’s compensating-controls guidance.

Agent: Running fido2_compliance_check on equipment-auth-list.md…

Agent: The check found 3 FIDO2-compliant entries (YubiKey 5, Windows Hello, corporate laptops with passkeys), 2 non-compliant (SMS for field crews, TOTP on the legacy billing portal), and 1 unknown (SCADA HMI — no MFA support). I’ve added a Transition roadmap table with target dates for moving off SMS and TOTP, and an MFA exception section for the SCADA HMIs: rationale (vendor EOL, no FIDO2 support), compensating controls (jump host with FIDO2, OT segment isolated, session logging), and review date. You can re-run the check after updating the equipment list to keep evidence current.

You: We’re switching field crews to YubiKeys. Update the list and run the check again.

Agent: Updated the list and re-ran fido2_compliance_check. Summary: 4 FIDO2, 1 non-compliant (legacy billing portal — already in roadmap), 1 unknown (SCADA). The evidence package is consistent with the new state.

What the Tools Validate

The skill includes one extension tool:

fido2_compliance_check scans an equipment or authentication-methods list and reports whether each entry meets the FIDO2/WebAuthn standard required by CISA CPG 1.1:

Input: Path to a Markdown or text file containing a table or bullet/numbered list of authentication methods or devices (e.g. “YubiKey 5”, “SMS”, “Windows Hello”, “SCADA HMI”).
Classification: Each entry is classified as:
- FIDO2 — Terms such as FIDO2, WebAuthn, passkey, security key, YubiKey, Windows Hello, Touch ID, Face ID, FIDO certified, phishing-resistant.
- NON_COMPLIANT — SMS, OTP, TOTP, authenticator app, push notification, email OTP, knowledge-based; these do not meet CPG 1.1 and should be migrated or documented as exceptions.
- UNKNOWN — No clear match; the tool suggests specifying whether the hardware is FIDO2 certified or documenting as a legacy exception.
Output: A line-by-line report with status and reason, plus a summary (counts of FIDO2, non-compliant, unknown) and a reminder to document exceptions and compensating controls for any non-compliant or legacy systems.
Use when building the current-state inventory, when proposing new hardware, or before finalizing the CPG 1.1 evidence package. Re-run after updating the equipment list so the evidence reflects the current proposed state.

Output Excerpt

A condensed excerpt from a generated CPG 1.1 implementation guide: transition roadmap and an MFA exception rationale, followed by a snippet of the compliance check report.

Transition roadmap (excerpt):

| System / population     | Current auth     | Target (CPG 1.1) | Target date | Notes                    |
|-------------------------|------------------|------------------|-------------|--------------------------|
| Corporate workstations  | Windows Hello    | FIDO2 (existing) | —           | Compliant                |
| Field crews             | SMS              | YubiKey 5        | Q2 2026     | Hardware ordered         |
| Billing portal (legacy) | TOTP             | FIDO2 / migration| Q4 2026     | Vendor roadmap required  |
| SCADA HMIs              | Password only    | Exception        | —           | See MFA exception below  |

MFA exception rationale (excerpt):

### MFA exception: SCADA HMIs (OT)

- **System:** [Plant name] SCADA HMIs; vendor EOL, no FIDO2/WebAuthn support.
- **Reason MFA cannot be applied:** Legacy OT stack; no support for hardware tokens or WebAuthn; replacement planned FY27.
- **Compensating controls:** (1) Access only via jump host with FIDO2; (2) OT segment isolated from IT; (3) Session and change logging; (4) Physical access control to control room.
- **Review date:** June 2026 (re-evaluate with replacement project).

Compliance check report (excerpt):

======================================================================
CPG 1.1 — FIDO2 / Phishing-Resistant MFA Compliance Check
File: equipment-auth-list.md
Entries checked: 6
======================================================================

[FIDO2] #1 — YubiKey 5
    Matches phishing-resistant/FIDO2 indicator: "yubikey".

[NON-COMPLIANT] #2 — SMS for field crews
    Not phishing-resistant per CPG 1.1: "sms". Migrate to FIDO2/WebAuthn or document as exception...

[UNKNOWN] #6 — SCADA HMI (vendor EOL)
    Could not determine FIDO2 compliance. Specify whether hardware is FIDO2/WebAuthn certified or document as legacy exception.

Summary: 3 FIDO2-compliant, 2 non-compliant, 1 unknown.
CPG 1.1 requires phishing-resistant MFA (FIDO2/WebAuthn). Document exceptions and compensating controls...
======================================================================

Getting Started

Add your source materials (e.g. equipment list, current auth methods, system inventory) to the project workspace, then activate the MFA Exception Rationalizer (CISA CPG 1.1) skill. The agent will run the FIDO2 compliance check on your list, draft transition roadmaps and exception rationales with compensating controls, and help you assemble the evidence package.