Implementation Status of MFA and Configuration Baselines on a Legacy Claims Portal
The system owner of a legacy claims portal reports IA-2(1) as 'Implemented' in the SSP. Evidence shows 1,200 internal users authenticate through the agency SSO with MFA, but 34 external claims adjusters use local portal accounts with passwords only because the portal cannot consume SAML assertions. A vendor patch is scheduled in nine months. Separately, CM-6 is documented with a hardened baseline, but a recent scan finds 12 of 40 servers deviate from the baseline after an emergency change to fix an outage. The change was approved verbally and never recorded. The AO is preparing for an assessment and asks how these should be represented.
1. How should IA-2(1) be recorded in the SSP, and what supporting artifacts are needed?
Read the worked answer
IA-2(1) should not be recorded as fully Implemented. The accurate status is Partially Implemented: MFA is enforced for 1,200 internal users, but 34 external claims adjusters authenticate with passwords only. The SSP should state the population covered, the population excluded, and why.
Supporting artifacts should include:
- An identity and authentication architecture diagram or narrative showing the SSO path and the local-account path.
- A list or count of the 34 accounts, their business justification, and compensating controls such as VPN restriction, network access control, session monitoring, least privilege, and enhanced logging.
- A POA&M with a milestone for SAML support or another MFA mechanism, and a risk statement for the interim period.
- Evidence that the system owner has informed the AO of the gap rather than hiding it in an 'Implemented' claim.
IA-2(1) is an MFA requirement. A password-only path for external users is a real gap even if the affected population is small. Calling it Implemented would misstate the implementation and could invalidate the assessment.
2. What is the correct treatment of the 12 deviating servers under CM-6 and CM-3?
Read the worked answer
CM-6 is other than satisfied for the 12 deviating servers unless the deviations are formally approved, risk-assessed, and reflected in the configuration baseline. A verbal approval during an outage is not adequate configuration change control.
The correct treatment is:
- Record the emergency change under CM-3, including what changed, why, who approved it, and the risk.
- Obtain retroactive written approval or direction from the change authority and the AO as appropriate.
- Either update the baseline with an approved deviation or remediate the 12 servers to the baseline.
- Add a POA&M if remediation will take time, and rescan to verify.
- Review CM-2 and CM-5 to determine why the baseline and change controls did not prevent unrecorded drift.
Twelve of forty servers is material, not a rounding error. The SSP should not describe CM-6 as fully implemented while those deviations remain unapproved. The system owner can explain the operational pressure, but the assessment record must show the control gap and the risk decision.
3. The system owner argues that because the deviations were needed to restore service, they should not be reported as a finding. How do you respond?
Read the worked answer
Operational necessity explains the change but does not erase the control failure. The assessor should report what was found: unrecorded deviations from the approved baseline and an emergency change without documented approval. The system owner can provide context, and the AO can accept the risk, but the finding should not be suppressed.
The distinction is important:
- Assessment result: CM-6 and CM-3 are other than satisfied for the affected servers.
- Risk decision: the AO may accept the residual risk temporarily because the change restored service.
- Remediation: document the change, obtain approval, update or restore the baseline, and verify by rescan.
If the agency later determines the emergency change was properly authorized under an emergency change procedure, the finding may be closed or downgraded with evidence. It should not be preemptively removed because the outage was real. Honest reporting protects the AO's authorization decision and the credibility of the assessment.