FedRAMP says your MFA probably doesn't count. Here's why.
FedRAMP requires phishing-resistant MFA. Most teams use TOTP. Most teams do not satisfy the requirement and do not realize it.
Here is what one Key Security Indicator actually requires, why your existing MFA likely does not satisfy it, and how to read any KSI for yourself.
What a KSI is, briefly
A Key Security Indicator (KSI) is the unit of evidence in the new FedRAMP 20x track. There are 64 of them grouped into 11 themes. Each KSI has a plain-English statement of an outcome the system needs to demonstrate, plus a list of underlying 800-53 controls it maps to. Compared to the legacy approach of organizing around 300+ control numbers, KSIs are easier to read, easier to test against actual systems, and easier to talk to engineers about.
The catalog is published as a single JSON file at github.com/FedRAMP/docs. You can open it today.
KSI-IAM-MFA, walked through
One indicator. Theme: IAM (Identity and Access Management).
KSI-IAM-MFA — "Enforcing Phishing-Resistant MFA."
The statement says, in plain English, that the system enforces multi-factor authentication that is resistant to phishing. The underlying 800-53 control is IA-2 (Identification and Authentication, Organizational Users), with related enhancements covering phishing-resistant authentication.
Read closely. The phrase "phishing-resistant" is doing real work.
Why your existing MFA probably is not phishing-resistant
CISA, the Cybersecurity and Infrastructure Security Agency, publishes guidance on what counts as phishing-resistant MFA. The short version is this. FIDO2 security keys and platform passkeys are phishing-resistant. PIV smart cards used by federal employees are phishing-resistant. App-based one-time-password (TOTP) generators, push notifications to a phone, and SMS codes are not.
The reason is mechanical. A phishing site can replay a TOTP code, a push approval, or an SMS in real time and authenticate as the user. A FIDO2 key cryptographically binds to the legitimate domain, so it refuses to sign for a look-alike. The federal government decided years ago that the difference matters. FedRAMP's KSI-IAM-MFA codifies that decision.
If your engineering team uses Google Authenticator, Authy, Microsoft Authenticator, Okta Verify push, or SMS as the second factor for production access, that is MFA. It is not phishing-resistant MFA. A 3PAO assessing this KSI will see the gap.
This is one of the most common surprises for first-time FedRAMP candidates.
Teams genuinely have MFA enabled. They are not lying. They are answering the wrong question.
How to read any KSI for yourself
Three steps.
Open the file. Go to github.com/FedRAMP/docs and look for FRMR.documentation.json. It is one JSON file. Do not read articles about it; read it.
Find the KSI block. The top-level structure has a "KSI" key that contains the 11 themes. Pick a theme. Pick an indicator inside it. Look at the name field, the statement field, and the controls array.
Follow the controls. The control IDs (like SC-8, IA-2, AU-2) reference NIST SP 800-53 Rev 5. The 800-53 catalog is also publicly available, and what each control means is one search away.
Thirty minutes with the actual file is worth many hours of articles. The catalog is short, structured, and human-readable.
What AWS gives you
If your federal deployment runs on AWS, the platform offers phishing-resistant MFA at no additional cost.
AWS IAM Identity Center supports FIDO2 security keys and passkeys natively for workforce sign-in. The AWS root account now requires MFA, and FIDO2 security keys are supported. If your federation goes through an external identity provider (Okta, Entra ID, Google Workspace), the IdP's phishing-resistant authentication methods pass through to AWS.
The configuration matters. AWS supporting phishing-resistant MFA does not mean your account is using it. Audit your IAM Identity Center settings, your IdP configuration, and any break-glass accounts. The KSI is asking what is enforced, not what is supported.
What to do this month
If your team is anywhere near a FedRAMP authorization, three things.
Audit how every human accesses production. List the IdP, the second factor, and the recovery flow. If anything in that list is TOTP, push, or SMS, write it down as a known gap.
Pick a phishing-resistant method and pilot it. FIDO2 security keys (YubiKey or similar) for one team, or passkeys on company-issued laptops, are the two common starting points. The cost is small. The change-management work is not zero, but it is the kind of thing engineering teams already know how to plan.
Document the rollout plan. KSI-IAM-MFA is one of the indicators where you can show progress. Showing a 3PAO "we currently use TOTP and our migration to FIDO2 is in flight, here is the timeline" is a defensible posture during an authorization. Showing them "we use TOTP and have no plan" is not.
The series
Part 1 — So your CEO just said we need FedRAMP. Start here.
Part 2 — FedRAMP just got a new authorization track. Here's what it looks like.
Part 3 — You are here.
Part 4 — What FedRAMP actually costs in 2026, with numbers — including the line items consultants tend to soft-pedal.
Part 5 — What is coming through 2028 so you can plan around it.