The school-district student application catalog must fail closed when UEM compliance cannot be read. How should the Access policy treat unknown device posture?
Select an answer to reveal the explanation.
Short Explanation
Unknown posture is a blank hall pass, and sensitive catalogs should not wave it through. Deny when compliance cannot be read. Allow-on-unknown is fail-open, which is the opposite of what the district asked.
Full Explanation
The school-district student application catalog must fail closed when UEM compliance cannot be read. Set the Workspace ONE Access policy to deny when device compliance cannot be determined—unknown posture is a blank hall pass, and sensitive student catalogs should not wave it through. Allowing access when device compliance cannot be read so students are not locked out fails by concept because allow-on-unknown is fail-open behavior, which is the opposite of the district’s fail-closed requirement. Ignoring compliance and requiring only a username fails because username-only authentication abandons device posture for a catalog that must respect UEM compliance state. Converting unknown compliance into an NSX-T tag that allows HTTPS fails because NSX tags and HTTPS allows are not Access fail-closed handling of undetermined UEM compliance. Exam caveat: fail-closed Access posture treats undetermined device compliance as deny—not allow-on-unknown, not username-only, and not NSX tag translation into an allow. Operational check: simulate an undetermined compliance response on a test path and confirm Access denies the student catalog; with known compliant managed devices confirm legitimate access still works; document that allow-on-unknown is prohibited for this catalog. Monitor UEM-to-Access compliance integration health so widespread undetermined states trigger operations response rather than silent fail-open pressure from helpdesk.