FedRAMP RFC-0036: KSI-IAM-MPI and Persistent NIST IAL3 for Class D

In our earlier articles on operationalizing NIST IAL3 as a continuous FedRAMP 20x Key Security Indicator and five automated IAL3 validation methods for Class D, we argued that high-assurance identity proofing belongs in a continuous program instead of a one-time onboarding checkbox. We have been running lifecycle-driven IAL3 verification for our FedRAMP High customers for some time, because the threat landscape demanded it. In July we predicted that Class D would name identity and personnel assurance as an outcome of its own, possibly scoped by risk.

With RFC-0036: FedRAMP 20x Class D Cloud-Hosted Pilot Requirements, opened for public comment on October 15, 2026, FedRAMP has proposed that indicator for the Phase 4 pilot.

RFC-0036 proposes 2 new definitions, updates to 6 rulesets, and 10 new Key Security Indicators (KSIs) for FedRAMP 20x Class D (High). The one that matters most to identity and security architects is KSI-IAM-MPI (Managing Personnel Identities). Its related controls are NIST SP 800-53 IA-12(4), In-Person Validation and Verification, the 800-53 counterpart of the on-site attended proofing that NIST SP 800-63A-4 requires at IAL3, and SI-4(19), Risk for Individuals. No indicator in the current 20x catalog maps IA-12(4); KSI-IAM-MPI would be the first.

Here is our breakdown of RFC-0036, why KSI-IAM-MPI ends the era of one-and-done IAL3 checks, how the Justice Department's October 13 actions, including Operation Lonestar Roundup, show the threat a one-time check misses, and how engineering and compliance teams should prepare.

FedRAMP RFC-0036 and NIST IAL3, in brief:

• The new identity indicator: RFC-0036 proposes KSI-IAM-MPI for 20x Class D: "the background and identity of personnel is persistently verified and validated, based on their privileges and assigned roles," with IA-12(4) and SI-4(19) as related controls.
• The shift to persistent verification: IAL3 stops being a Day 1 hiring gate. Together with suitability monitoring of privileged and high risk resources (KSI-IAM-MST), persistent validation means verifying people again across the employee lifecycle, which is what stops post-hire proxy handoffs and laptop farms.
• The 4-hour telemetry bar: Class D providers already need at least 4 automated methods per KSI. Under the revised SDR-CSX-KMT, they would also supply metric data, including status of persistent validation, every 4 hours for up to the past year, alongside 30-day and 1-year summaries.
• Certified third-party services: the new FRC-CLD-CTP recommends (SHOULD) that Class D providers limit the likely handling of federal customer data to third-party services in FedRAMP certified offerings. When Trust Swiftly proofs a provider's personnel, the offering's federal customer data never reaches us, and we are pursuing FedRAMP certification anyway.

What Is in FedRAMP RFC-0036?

RFC-0036 is a request for comment: a proposal open for feedback until November 19, 2026. It proposes changes to test in the FedRAMP 20x Phase 4 pilot for cloud-hosted Class D offerings, and FedRAMP expects the rules and indicators to change based on feedback during the pilot. Because Class D is the highest assurance tier for federal workloads, the proposal raises the bar in three areas: identity and foreign ownership risk, high-frequency automated telemetry, and progressive assurance.

The rules and indicators below are the ones most relevant to identity, telemetry, and assurance. The full RFC also proposes indicators for non-production testing, cryptographic access, encrypted data inspection, and automated security tooling, plus a new rule, VER-EVA-IOC: when a detected vulnerability is likely enough to be exploited, Class D providers SHOULD start forensic work such as searching for indicators of compromise.

The FOCI indicators are identity work too. Hidden foreign ownership, control, or influence, through proxy owners, disguised funding, or a few people in key positions, gives a nation state a foothold that a paper review misses. In March we flagged FOCI as critical for that reason: identity verification finds the hidden links that paperwork does not show. RFC-0036 now proposes four Class D indicators for it.

RFC-0036's two new definitions set their scope. FRD-FOR defines FOCI as a foreign entity having the power to direct or influence the management or operations of an offering agencies rely on. FRD-FPS adopts the definition of a foreign person in the CFIUS regulations, 31 CFR 800.224: any foreign national, foreign government, or foreign entity, or any entity that one of them controls or can control. Because a foreign person can sit behind an entity that looks domestic, persistently reviewing foreign persons under KSI-PIY-RFP starts with verifying who actually owns and controls the business.

Why KSI-IAM-MPI and IA-12(4) Point to IAL3 for Class D

In the current 20x catalog, workforce identity proofing sits inside KSI-IAM-AAM (Automating Account Management). FedRAMP maps that indicator to IA-12 and three of its enhancements: identity evidence (IA-12(2)), evidence validation and verification (IA-12(3)), and address confirmation (IA-12(5)). IA-12(4) is not among them. That left teams wondering how Class D would set its identity proofing expectations apart from Class C (Moderate).

RFC-0036 answers that with a dedicated indicator:

KSI-IAM-MPI: "The background and identity of personnel is persistently verified and validated, based on their privileges and assigned roles."

Related controls: IA-12(4), SI-4(19)

Two NIST SP 800-53 Rev. 5 control enhancements anchor it:

1. IA-12(4), Identity Proofing: In-Person Validation and Verification. "Require that the validation and verification of identity evidence be conducted in person before a designated registration authority." FedRAMP assigns it to Class D (High), not Class C (Moderate). In NIST SP 800-63A-4, IAL3 SHALL be on-site attended, and the proofing agent may attend in the room or through a CSP-controlled kiosk or device (§4.3.1). FedRAMP's Rev5 guidance for Class D already requires authenticators compliant with NIST's digital identity guidelines at IAL, AAL, and FAL level 3.
2. SI-4(19), System Monitoring: Risk for Individuals. Additional monitoring of individuals identified as posing an increased level of risk. RFC-0036 pairs it with KSI-IAM-MST (Monitoring Suitability), which adds SI-4(20) for privileged users.

By joining IA-12(4) and SI-4(19) in one indicator and adding the word "persistently," FedRAMP is making an architectural statement, and our reading of it is this:

Under KSI-IAM-MPI, IAL3 becomes a lasting state of assurance: established at onboarding, then verified and validated again throughout a worker's tenure, in step with their privileges.

FedRAMP defines "persistently" as repeated in intentional, documented cycles with the status always known, so the indicator asks for re-verification triggers and a schedule that an assessor can test.

Class D SaaS on Class C Hosting: The Support Staff Risk

FRC-CLD-CCH lets a Class D offering deploy on a FedRAMP Class C certified IaaS or PaaS. As proposed, KSI-IAM-MPI is a Class D indicator, and nothing in the RFC extends it to the people who operate a Class C platform. For a Class D SaaS provider, that makes the platform's support staff a major risk: a platform may run support with engineers around the world, some of whom cannot be properly vetted.

If your platform has international operators, prepare for the scenario where one is compromised and uses privileged access to reach your account. Even with limited privileges, an operator can be used for reconnaissance, building a clear picture of your infrastructure to hand to an attacker.

One way around the data risk is for the SaaS to encrypt federal data itself, using customer-managed encryption keys (CMEK) that it holds outside the platform, in a key manager or HSM the platform's operators cannot reach. The platform's storage and managed services then hold only ciphertext, and the platform has no key to read it. CMEK does not hide your architecture, though, and it moves the trust to whoever holds the keys. Our reading: on Class C hosting, treat the platform's operators as outside your trust boundary and carry KSI-IAM-MPI's personnel assurance at your own layer. Limit and record what platform support can see, and persistently verify, at IAL3, the engineers on your team who hold the keys and your control-plane access.

Why One-Time IAL3 Falls Short

On October 13, 2026, the U.S. Department of Justice announced coordinated actions against North Korean remote IT worker schemes, including Operation Lonestar Roundup in Texas, and the FBI's public service announcement the same day warns that paid U.S. facilitators now appear on camera, sit job interviews, verify fraudulent identities and host company laptops in "laptop farms." The FBI's answer is "identity in depth," which includes "continuous identity verification throughout employment," and that is what KSI-IAM-MPI asks of personnel identities. We covered how these schemes recruit and operate in How to Reduce Nation-State and Proxy-Hire Risk in Remote IT Teams.

How Persistent IAL3 Stops the Proxy Handoff

If NIST IAL3 is only a pre-employment hurdle, a cooperative U.S. proxy can sit in front of a camera on Day 1, complete onboarding, and hand the corporate laptop and the bound hardware security key to a laptop farm on Day 2.

We have been running persistent IAL3 verification for our FedRAMP High customers to close this gap. Mapped to KSI-IAM-MPI, it puts identity in depth into practice, verifying the person behind the keyboard at five triggers:

1. Initial attended IAL3 proofing on controlled hardware. On an IAL3 Kit from our 200+ device fleet or an office kiosk, never an unmanaged personal webcam exposed to virtual camera injection and deepfakes, a trained agent validates SUPERIOR or STRONG evidence such as a chip-enabled passport, runs presentation attack detection conformant to ISO/IEC 30107-3:2023, captures a facial biometric, and binds an AAL3 hardware authenticator in the same attended session.
2. Re-verification at privilege escalation and role change. KSI-IAM-MPI says "based on their privileges and assigned roles." When an engineer moves from non-production to production access, receives break-glass privileges, or takes on a high-risk role, the identity governance (IGA) pipeline triggers a step-up IAL3 re-verification before the grant takes effect.
3. Biometric-gated recovery under NIST SP 800-63B-4. A request to replace a "lost" security key or enroll a new device soon after onboarding is one warning sign of a handoff. When every AAL3 authenticator on an IAL3 account is lost, SP 800-63B-4 requires a biometric comparison against the sample retained from the attended session before a new one is bound, so the person proofed on Day 1 is the person who receives the replacement. Trust Swiftly runs that comparison and records it.
4. Risk-triggered re-proofing (SI-4(19) and KSI-IAM-MST). When EDR, network telemetry, or the SIEM raises indicators that fit SI-4(19), such as impossible travel, unexpected USB or KVM hardware, residential proxy routing, or anomalous working hours, access is suspended until the user completes an attended re-verification that confirms possession of their identity evidence and matches the enrolled biometric.
5. Periodic re-verification. For privileged operators and high-risk contractors, scheduled re-verification confirms that the enrolled person still holds the bound authenticators. Our retention and re-verification guidance covers how to set the interval by risk.

Meeting the 4-Hour Telemetry Bar: SDR-CSX-KMT and Four Automated Methods

RFC-0036 does more than add KSI-IAM-MPI. It also sets how often Class D providers must show that their indicators are working.

Under the Consolidated Rules, FRC-CSX-VVK already requires Class D providers to use at least 4 automated methods to persistently verify and validate each KSI, and RFC-0036 encourages them "to go well beyond this." Today's SDR-CSX-KMT asks Class C for daily metric data and leaves the Class D specifics to the Phase 4 pilot. RFC-0036 sets them. For each applicable KSI, the Security Decision Record would include:

1. A summary of each metric over the past 30 days.
2. A summary of each metric for up to the past year, where available.
3. Metric data, including status of persistent validation, every 4 hours for up to the past year, where available.

FedRAMP's note says this should be supplied through an API, and the new CDS-CSX-API requires Class D providers to supply all machine-readable parts of the certification package that way.

Our September architecture article on five automated IAL3 validation methods recommended real-time checks at every state transition plus a daily sweep, in line with the daily data Class C requires. At the proposed Class D cadence, the sweep runs every 4 hours, and the five methods map onto it directly:

Methods 1, 4, and 5 reconcile against the proofing provider's records. Trust Swiftly's real-time API, its webhooks for completion, binding, and revocation events, and its OSCAL evidence output feed those methods directly, so each 4-hour snapshot is produced by automation instead of compiled in a spreadsheet.

Method 4 also lines up with another new Class D indicator. KSI-SVC-UAS (Using Automated Security) lists PS-4(2), automated actions on personnel termination, among its related controls, and session_invalidation_seconds shows how quickly automation ends a worker's sessions after revocation.

Certified Third-Party Services (FRC-CLD-CTP), and Why Trust Swiftly Is Pursuing Certification

RFC-0036 also adds FRC-CLD-CTP: Class D providers "SHOULD limit the likely handling of federal customer data within the cloud service offering to third-party information resources that are included in a FedRAMP Class B, Class C, Class D, or Class G Certified offering."

Class G is not a typo. FedRAMP has explained that cloud offerings provided by federal agencies, certified through the separate process proposed in RFC-0032, Offerings By Government, will be Class G if the FedRAMP Board approves it.

For workforce proofing, this changes little. The rule is a recommendation, and it covers federal customer data. When Trust Swiftly proofs your personnel, your offering's federal customer data never reaches us: proofing runs in its own isolated structure, separate from your offering's federal data.

We would still rather exceed the recommendation than debate whether it applies, so we are pursuing FedRAMP certification for two reasons:

• Third-party scrutiny will widen. FedRAMP already looks at third-party risk as part of the whole offering, and its note on this rule says it exists so agencies can assess "the full lifecycle of federal customer data." We expect that scrutiny to reach the entire supply chain, down to small APIs and ancillary services. As providers close their own gaps, the remaining openings get smaller, and attackers turn to more distant networks and relationships. If the rule tightens, working with a certified identity provider means you are already prepared.
• Personal information demands it. Any company that processes PII should meet a high security bar, whether or not federal data is involved. Trust Swiftly already holds a SOC 2 Type II report, and certification raises that bar again.

Trust Swiftly is also US-founded, US-owned and operated, so choosing us adds no foreign business relationship to your KSI-PIY-RFB review.

How to Prepare for the FedRAMP 20x Class D Pilot Now

Under FRC-CLD-PCD (Progressive Certification to Class D), providers seeking 20x Class D need a 20x Class C certification held without corrective action for at least 6 months, unless FedRAMP grants an exemption for an urgent critical need. For the Phase 4 pilot, a full non-pilot 20x Class C certification is required to participate, but the 6 months is not. If you already hold a Rev5 Class D (High) certification, FedRAMP's note on the rule says you will not be expected to give it up, but a move to 20x Class D still runs through 20x Class C first.

RFC-0033 set target dates for the pilot, which assume "no unexpected bumps in the road," and a firm maximum of 10 participants:

• November 13, 2026: if you apply for 20x Class C before this date and intend to join the pilot, send the FedRAMP Director a notice of intent after the Class C application is submitted.
• November 19, 2026: the RFC-0036 comment period closes.
• Before December 1, 2026: receive a CR26-compliant 20x Class C certification, the single requirement to apply.
• December 1 to 4, 2026: the pilot application window.
• February 17, 2027: mandatory draft package submission and initial progress review.
• March 17, 2027: final pilot package submission deadline.

SDR-CSX-KMT asks for up to a year of historical metrics, where available, but a short history does not lock you out. The current rule's note says that for initial certification, a provider whose service has not been operating with the metrics for the required period needs the mechanisms in place and must agree to meet the requirement. The automated pipeline is the gate to clear before you apply, and validation history cannot be backdated, so teams targeting Class D should take four steps now:

1. Move from one-time proofing to lifecycle KSI-IAM-MPI workflows. Map every role and privilege transition in your boundary (IA-12(4)) and connect high-risk user monitoring (SI-4(19)) to step-up IAL3 re-verification and biometric-gated recovery.
2. Retire unmanaged personal-device proofing. Replace software-only webcam checks with attended sessions on controlled hardware, shipped IAL3 Kits or office kiosks, to shut out laptop farms, KVM proxies, and virtual camera injection.
3. Run four or more automated validation methods on a 4-hour cycle. Connect your directory, identity provider, gateway logs, and the Trust Swiftly ledger API so validation telemetry reaches your Security Decision Record pipeline every 4 hours.
4. Comment on RFC-0036. FedRAMP is asking for feedback on the clarity, applicability, reasonability, and achievability of the proposed rules and indicators until November 19, 2026. Formal comments go in Discussion #180, the RFC-0036 thread on GitHub. FedRAMP can't answer questions in an RFC thread, to avoid influencing public comment, so questions and informal discussion go in its side thread, Discussion #181, where FedRAMP staff reply. A post there does not replace a formal comment.

Frequently Asked Questions

What is KSI-IAM-MPI in FedRAMP RFC-0036?

KSI-IAM-MPI (Managing Personnel Identities) is a new Key Security Indicator that RFC-0036 proposes for FedRAMP 20x Class D only. It states that "the background and identity of personnel is persistently verified and validated, based on their privileges and assigned roles," and lists NIST SP 800-53 IA-12(4), in-person validation and verification of identity evidence, and SI-4(19), risk for individuals, as related controls.

Does KSI-IAM-MPI make NIST IAL3 a one-time check or an ongoing one?

Ongoing. KSI-IAM-MPI asks for personnel identity to be persistently verified and validated, based on privileges and roles. In practice, an initial attended NIST SP 800-63A-4 IAL3 session establishes the identity and retains a biometric sample, and re-verification follows at role and privilege changes, account recovery, scheduled intervals, and risk triggers under SI-4(19) and KSI-IAM-MST. That is what stops a post-hire handoff, where a legitimate-looking hire passes Day 1 and then passes the corporate laptop to a laptop farm.

How often must KSI-IAM-MPI metrics be updated under FedRAMP 20x Class D?

Under SDR-CSX-KMT as revised by RFC-0036, Class D providers would supply, for each applicable KSI, a 30-day summary, a summary for up to the past year, and metric data, including status of persistent validation, every 4 hours for up to the past year, where available. FedRAMP's note points to an API under the new CDS-CSX-API rule. Each KSI is also validated by at least 4 automated methods under FRC-CSX-VVK. A provider applying for initial certification without that history needs the mechanisms in place and must agree to meet the requirement, under the current rule's note.

Do FedRAMP Rev5 High (Class D) providers have to go through 20x Class C?

To move to 20x Class D, yes, as proposed. FedRAMP's note on FRC-CLD-PCD says no one with a Rev5 Class D certification will be expected to give it up, but a transition from Rev5 Class D to 20x Class D still moves through 20x Class C first. FedRAMP expects most Rev5 Class D offerings to keep their Rev5 certification even after obtaining 20x Class D.

Does FedRAMP 20x Class D require our IAL3 provider to be FedRAMP certified?

No, not as proposed. FRC-CLD-CTP says Class D providers SHOULD limit the likely handling of federal customer data to third-party services in a FedRAMP certified offering. It is a recommendation, and it covers federal customer data, which never reaches us when we proof your personnel. We are pursuing FedRAMP certification anyway, because third-party scrutiny is likely to widen and any company that processes personal information should meet a high security bar.

The Bottom Line

FedRAMP RFC-0036 sends a clear signal to cloud providers targeting 20x Class D (High): personnel identity assurance is anchored to IA-12(4) in-person proofing, which NIST IAL3 delivers, and it is verified persistently rather than once at hiring. As the Justice Department's October 2026 actions and the FBI's warning about paid facilitators showed, North Korean operators rely on U.S.-based helpers and laptop farms to get past Day 1 hiring gates. Persistent IAL3 verification on controlled hardware, backed by biometric-gated recovery and automated ledger validation every 4 hours, closes that gap.

Ready to put KSI-IAM-MPI and persistent NIST IAL3 into practice for FedRAMP High and 20x Class D?

• Explore our NIST IAL3 identity proofing platform and federal identity proofing options.
• Read the companion articles on five automated IAL3 validation methods and the NIST IAL3 conformance criteria checklist.
• Book a demo to test an IAL3 Kit and start building your Class D validation history today.