Class B → C

63 of the 167 controls this step adds are orphans: no 20x Key Security Indicator reaches them. The consequence is structural rather than editorial — the control graph this site is built on is assembled from indicator edges, so an orphan has no node, no /control/ permalink, and cannot be dispositioned on the automation frontier, whose universe is the KSI-reached set. They are enumerated here and nowhere else on the site, and the ids below are deliberately not links.

Added controls grouped by the recipe that reaches the control or, for an enhancement, the base control it tightens. A recipe on a base control is a lead for scoping, never evidence for the enhancement — a covered base is why the lower authorization is held. Each control is listed once, under whichever candidate mechanism carries the most of this step, so the counts partition the added set rather than double-count it. Where a control has more than one candidate, the full set is in its row of the table below.

• 6config-threat-monitoring-enabledawssi-4.1 · si-4.2 · si-4.4 · si-4.16 · si-4.18 · si-4.23
• 6iam-account-authorization-detailsawsac-2.1 · ac-2.5 · ac-2.7 · ac-2.9 · ac-2.12 · ac-6.1
• 5identity-center-jit-elevation-workflowawsac-6 · ac-6.2 · ac-6.5 · ac-6.9 · ac-6.10
• 5securityhub-incident-review-proceduresawsir-4.1 · ir-6.1 · ir-6.3 · ir-7.1 · si-4.5
• 4config-network-boundary-protectionawssc-7.7 · sc-7.8 · sc-7.12 · sc-7.18
• 4iam-credential-reportawsia-2.5 · ia-2.6 · ia-5.2 · ia-5.7
• 4patch-and-vulnerability-remediationawsra-5.3 · ra-5.5 · si-2.2 · si-2.3
• 4remote-access-authorization-and-monitoringawsac-17.1 · ac-17.2 · ac-17.3 · ac-17.4
• 3boundary-access-points-and-default-denyawssc-7.3 · sc-7.4 · sc-7.5
• 3config-least-functionalityawscm-7.1 · cm-7.2 · cm-7.5
• 3ssm-configuration-baseline-enforcedawscm-2.3 · cm-2.7 · cm-6.1
• 3static-analysis-coverage-and-flaw-dispositionpipelinesa-11 · sa-11.1 · sa-11.2
• 2audit-reduction-and-report-generationawsau-7 · au-7.1
• 2change-authority-restrictions-and-enforcementawscm-5.1 · cm-5.5
• 2cloudtrail-config-change-historyawscm-3 · cm-3.2
• 2cloudwatch-log-review-alertingawsau-6.1 · au-6.3
• 2config-asset-inventoryawscm-2.2 · cm-8.1
• 2config-data-backup-enabledawscp-9.1 · cp-9.8
• 2external-access-inventory-and-trust-boundaryawsac-20.1 · ac-20.2
• 2guardduty-incident-after-actionawsir-3 · ir-3.2
• 2guardduty-suspicious-iam-activity-responseawsac-2.4 · ac-2.13
• 2iam-access-analyzer-unused-accessawsac-2.3 · ac-6.7
• 2information-location-and-classificationawscm-12 · cm-12.1
• 2integrity-verification-and-immutabilityawssi-7 · si-7.1
• 1backup-restore-testingawscp-10.2
• 1build-provenance-attestation-verificationpipelinesi-7.7
• 1change-verification-status-checks-and-run-recordspipelinecm-4.2
• 1config-cloudtrail-audit-loggingawsau-9.4
• 1dependency-vulnerability-monitoringpipelinesr-6
• 1developer-change-control-and-integritypipelinesa-10
• 1error-handling-information-exposure-scanningpipelinesi-11
• 1identifier-assignment-and-reuse-preventionawsia-4.4
• 1input-validation-taint-analysis-coveragepipelinesi-10
• 1mobile-code-admission-and-bundle-provenancepipelinesc-18
• 1secret-exposure-detection-and-push-protectionpipelineia-5.6
• 1security-representative-change-approvalpipelinecm-3.4
• 1session-authenticity-tls-terminationawssc-23
• 1temporary-account-automatic-revocationawsac-2.2
• 1unauthorized-component-detection-and-responseawscm-8.3

Requirements whose timeframe is stated per class and differs across this step. A baseline diff cannot see these: the requirement id is identical in both classes and only the number moves. Units are the dataset’s own and are never converted.

The rest of the per-class rules: requirements whose class levels differ in force or in wording and carry no timeframe to diff. The clock table above cannot see these, and for the step to the highest class they are where the machine-automation requirement actually lives — the quota is stated as a count and the history window as prose, so neither is a number a clock diff can compare. Statements are the dataset’s own and are never paraphrased. A requirement that names its own class and is otherwise identical at both is counted as unchanged.

• CMU-CSO-UVMUsing Validated Cryptographic ModulesMAY → SHOULD

  Class B

  Providers with Class B Certifications MAY use cryptographic modules or update streams of cryptographic modules with active validations under the NIST Cryptographic Module Validation Program when using cryptographic services to protect federal customer data.

  Class C

  Providers with Class C Certifications SHOULD use cryptographic modules or update streams of cryptographic modules with active validations under the NIST Cryptographic Module Validation Program when using cryptographic services to protect federal customer data.

• FRC-CSX-MOTMetrics Over Time for Key Security IndicatorsSHOULD → MUST

  Class B

  Providers seeking 20x Class B Certification SHOULD supply historical metrics for Key Security Indicators.

  Class C

  Providers seeking 20x Class C Certification MUST supply historical metrics including status from persistent validation over at least the past 6 months for all Key Security Indicators.

• FRC-CSX-VVKAutomated Verification and Validation of Key Security IndicatorsSHOULD → MUST

  Class B

  Providers seeking 20x Class B Certification SHOULD implement automated methods to persistently verify and validate the accuracy and completeness of Key Security Indicators with at least 1 automated method for each Key Security Indicator.

  Class C

  Providers seeking 20x Class C Certification MUST implement automated methods to persistently verify and validate the accuracy and completeness of Key Security Indicators with at least 2 automated methods for each Key Security Indicator.

• VDR-TFR-PVRMitigation and Remediation Expectations

  Class B

  Providers with Class B Certifications SHOULD partially mitigate vulnerabilities, fully mitigate vulnerabilities, or remediate vulnerabilities to a lower potential agency impact within the timeframes from evaluation shown below, factoring for the current Potential Agency Impact N-rating as defined in VER-EVA-EPA (Estimate Potential Agency Impact), internet reachability, and likely exploitability:

  Class C

  Providers with Class C Certifications SHOULD partially mitigate vulnerabilities, fully mitigate vulnerabilities, or remediate vulnerabilities to a lower Potential Agency Impact N-rating within the timeframes from evaluation shown below, factoring for the current Potential Agency Impact N-rating as defined in VER-EVA-EPA (Estimate Potential Agency Impact), internet reachability, and likely exploitability:

• VER-TFR-IRIInternet-Reachable IncidentsMAY → SHOULD

  Class B

  Providers with Class B Certifications MAY treat internet-reachable likely exploitable vulnerabilities where Potential Agency Impact N-rating > 3 as a FedRAMP Reportable Incident until they are partially mitigated vulnerabilities at N3 or below.

  Class C

  Providers with Class C Certifications SHOULD treat internet-reachable likely exploitable vulnerabilities where Potential Agency Impact N-rating > 3 as a FedRAMP Reportable Incident until they are partially mitigated vulnerabilities at N3 or below.

• AC 32
• CM 18
• SI 18
• CP 17
• SC 15
• SA 12
• IA 11
• IR 10
• PE 9
• AU 6
• MA 6
• CA 4
• MP 3
• RA 3
• AT 1
• PS 1
• SR 1