After a change window, the housing authority needs continuous proof that resident-portal MFA still completes successfully. Which testing approach best provides that assurance?

Synthetic login transactions that exercise the MFA path and alert on failures provide continuous, proactive assurance that the housing authority’s resident portal still completes multifactor authentication after change windows. Synthetic (or robotic) transactions act as a controlled benchmark user journey: they authenticate, complete MFA challenges, and raise alerts when the path breaks—detecting misconfigured IdP rules, certificate problems, or blocked second factors before residents discover them. That approach matches Domain 6 expectations for testing critical processes with benchmarks and continuous verification rather than waiting for incidents.

Waiting for residents to complain is purely reactive and transfers detection of security-control failure onto citizens who may abandon the portal or call overwhelmed help desks. Disabling MFA temporarily to simplify change validation removes a critical control precisely when change risk is highest and creates an unauthorized security exception. Relying solely on an annual paper attestation that MFA ‘should work’ is a static assertion without evidence of current operability after frequent changes.

Exam caveat: Synthetic transactions and continuous monitoring verify availability and correct function of security controls in user journeys; they complement but do not replace penetration tests or code review. When the stem emphasizes continuous proof after changes, prefer synthetic/benchmark testing over complaint-driven or paperwork-only approaches.

Operational check: Script MFA journeys for representative resident account types, run them on a schedule and after each IdP or portal deploy, alert on failure with on-call ownership, track success rate as a KPI, and never suppress MFA for ‘easier validation’ without a time-boxed, documented exception approved by the housing authority CISO.