Legacy court case-management software cannot enforce MFA natively, yet remote clerks must keep using it. What is the most appropriate response?
Select an answer to reveal the explanation.
Short Explanation
When the old court app cannot do MFA itself, do not shrug and leave the door unlocked. Wrap it—proxy MFA, tighten the path, watch it closer—and write down why that wrap is the temporary brace.
Full Explanation
Legacy court case-management software that cannot enforce MFA natively still handles sensitive case data for remote clerks, so the MFA gap cannot be ignored. The appropriate response is to document the exception and apply compensating controls: front the application with a reverse-proxy or identity gateway that enforces MFA before sessions reach the legacy app, restrict the network path (VPN/ZTNA, allowlisted source ranges, no direct internet exposure), and enhance monitoring for anomalous remote use, while tracking remediation or replacement on the risk register. Ignoring the gap because the app is old invents an exemption that auditors and attackers will not honor. Requiring clerks to paste passwords into shared team chat creates additional credential exposure and shared-secret chaos. Removing all authentication to “simplify” remote access maximizes unauthorized access risk. Exam caveat: CISSP accepts compensating controls when native control is infeasible, but only with documentation, residual-risk acceptance, and layered mitigations—not wishful exemptions. Operational check: publish the MFA exception with owner and expiry, deploy the MFA gateway, verify remote clerks cannot reach the app without MFA, tighten firewall rules to the proxy only, and review enhanced logs weekly until the legacy platform is upgraded or replaced.