A water utility requires multifactor authentication at the statewide identity provider and a compliant enrolled device before SCADA-adjacent web tools open. How should the administrator layer those controls?
Select an answer to reveal the explanation.
Short Explanation
MFA at the state desk proves who is knocking; Access still checks whether the laptop is a city device. Stack both—do not drop compliance because MFA exists.
Full Explanation
When a water utility requires multifactor authentication at the statewide identity provider and a compliant enrolled device before SCADA-adjacent web tools open, the administrator should keep MFA at the third-party IdP and require device compliance in the Workspace ONE Access policy. Treat MFA as proving who the operator is and Access device compliance as proving which civic laptop they hold—both layers are required at the SCADA-adjacent door. Disabling Access device compliance because the IdP already prompts for MFA fails by concept because IdP MFA authenticates the user but does not evaluate UEM device posture. Replacing Access with an NSX-T Gateway Firewall geolocation rule fails because geolocation at the gateway is not layered identity-plus-device SSO for web tools. Trusting any device that presents a Carbon Black Cloud sensor UUID fails because a sensor UUID is not Access compliance evaluation of an enrolled device. Exam caveat: layer IdP MFA with Access policies that require compliant enrolled devices; MFA alone, gateway geolocation, or sensor UUID trust are incomplete. Operational check: confirm MFA at the statewide IdP, require UEM compliance in the Access policy for SCADA-adjacent apps, test with a non-compliant device expecting deny, and document the layered control in the utility access standard.