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. Trust Swiftly never handles federal customer data and is 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.
| Rule or indicator | Name | What it proposes for 20x Class D |
|---|---|---|
| KSI-IAM-MPI | Managing Personnel Identities | 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). |
| KSI-IAM-MST | Monitoring Suitability | Privileged and high risk information resources have their access, privileges, suitability, and activities persistently reviewed and evaluated. FedRAMP's note says this includes personnel, funds, and technology such as AI agents. Related controls: SI-4(19), SI-4(20). |
| SDR-CSX-KMT | Key Security Indicator Metrics | Historical metrics in the Security Decision Record 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. |
| CDS-CSX-API | API Certification Data | New: providers MUST responsibly supply all machine-readable parts of the FedRAMP Certification Package through a web-compatible API. |
| FRC-CLD-PCD | Progressive Certification to Class D | Providers MUST hold a 20x Class C Certification without corrective action for at least 6 months, or receive an exemption for an urgent critical need. For the Phase 4 pilot, a full non-pilot 20x Class C Certification is required, but the 6 months is not. |
| FRC-CLD-CCH | Certified Cloud Hosting | New: providers MUST deploy on a FedRAMP Class C or Class D Certified IaaS or PaaS offering, or meet Class D self-hosted or hybrid-hosted rules that FedRAMP will develop separately. |
| FRC-CLD-CTP | Certified Third-Party Services | New: providers SHOULD limit the likely handling of federal customer data to third-party information resources included in a FedRAMP Class B, C, D, or G Certified offering. |
| VDR-TFR-MVX, VER-TFR-MRH | Persistent Machine Verification and Validation; Historical Activity | Verify and validate the status of machine-based resources at least once every 3 days (MUST). Make recent vulnerability detection and response history available in JSON for automated retrieval (raised from SHOULD to MUST), updated at least once every 7 days (SHOULD). |
| CMU-CSO-PQS | Post-Quantum Cryptography Status | New: document whether the algorithms for key establishment and digital signatures that protect federal customer data are post-quantum, hybrid, or neither, with a target transition date where available and applicable. |
| KSI-PIY-DFC, RFP, RFB, MFD | Four new FOCI indicators | Detect changes in foreign ownership, control, or influence (FOCI); persistently review foreign persons able to direct or decide matters affecting the offering and the foreign business relationships that support it; and maintain FOCI determinations or mitigation agreements. Under the companion rule FRC-FRA-FOD, FedRAMP itself will not request FOCI details or judge them. |
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.
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 its enhancements for identity evidence, evidence validation and verification, and address confirmation, IA-12(2), IA-12(3), and IA-12(5), but not to IA-12(4). 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:
- 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.
- 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.
Why One-Time IAL3 Falls Short: Lessons from Operation Lonestar Roundup
Why insist that personnel identities be persistently verified and validated (KSI-IAM-MPI), alongside suitability monitoring of privileged and high risk resources (KSI-IAM-MST)? Because nation-state operators have adapted to defeat one-time hiring checks.
On October 13, 2026, the U.S. Department of Justice announced coordinated actions against North Korean remote IT worker schemes. In the Northern District of Ohio, an indictment charges 14 people over a scheme that affected more than 70 U.S. companies, in sectors including health care, communications, cyber support, retail, and manufacturing. In Texas, the FBI ran Operation Lonestar Roundup against suspected laptop farms.
The details show why a single check at hiring fails:
- More than 40 suspected laptop farms and about 187 seized devices. Between September 21 and September 25, the FBI searched more than 40 Texas residences known or suspected to be operating as laptop farms. Over the whole operation it seized approximately 187 laptops and KVM (keyboard, video, mouse) devices.
- Americans paid to stand in. The FBI's accompanying public service announcement warns that North Korean IT workers increasingly rely on facilitators, including Americans, to counter improved private sector detection and law enforcement action. Facilitators are paid to appear on camera, sit job interviews, verify fraudulent identities, and keep work devices online from their homes. Some teams land a job and then subcontract the work to freelancers abroad.
- Post-hire handoffs. A person who looks legitimate can pass the interview and the initial identity check. The corporate laptop then sits at a facilitator's residence, controlled through KVM-over-IP hardware by someone the employer never verified.
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 verifies the person behind the keyboard at five triggers:
- Initial attended IAL3 proofing on controlled hardware. On a Remote 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.
- 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.
- 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.
- 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.
- 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:
- A summary of each metric over the past 30 days.
- A summary of each metric for up to the past year, where available.
- 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:
| Automated method | What it validates for KSI-IAM-MPI | What it feeds the 4-hour SDR-CSX-KMT data |
|---|---|---|
| 1. Ledger reconciliation | Reconciles every boundary identity in IAM and PAM against the proofing ledger: IAL3, valid status, matching package hash, completion before the access grant, and re-verification still within its window. | coverage_pct and violations every 4 hours, plus a synchronous gate on every grant and role change. |
| 2. Enforcement configuration | Reads live identity provider and gateway policy through their APIs and diffs it against infrastructure-as-code state, so IAL3 and AAL3 rules cannot drift unnoticed. | config_drift_findings on every cycle and every deploy. |
| 3. Behavioral probing | Runs an automated negative probe with a synthetic, unproofed test identity to confirm that enforcement points refuse access. | negative_probe_refused every 4 hours. |
| 4. Session-to-record reconciliation | Joins gateway, identity provider, and cloud audit sessions against the webhook-fed proofing, re-verification, and revocation status table. | unmatched_sessions and session_invalidation_seconds every 4 hours. |
| 5. Bound-authenticator posture | Checks at every login that the authenticator entered the account through a permitted SP 800-63-4 binding path (the initial attended session, a binding made under AAL3 authentication, or a biometric recovery) and that the login achieved AAL3. | Per-session decisions, rolled up as auth_denied into each 4-hour snapshot. |
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.
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."
For workforce proofing, this changes little. The rule is a recommendation, and it covers federal customer data, which Trust Swiftly never handles: proofing your personnel 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. Either way, SDR-CSX-KMT asks for up to a year of historical metrics, where available.
Validation history cannot be backdated, so teams targeting Class D should take four steps now:
- 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.
- Retire unmanaged personal-device proofing. Replace software-only webcam checks with attended sessions on controlled hardware, shipped Remote Kits or office kiosks, to shut out laptop farms, KVM proxies, and virtual camera injection.
- 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.
- 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, in the RFC-0036 discussion on GitHub.
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.
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 Trust Swiftly never handles. 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 a Remote Kit and start building your Class D validation history today.
