Managing Security Policies and Access Controls
Core concepts
Security controls include 2-Step Verification (2SV) enforcement, security keys, context-aware access, password policies, OAuth app control, and API access control. 2SV enforcement is set at the OU/group level and can be phased with a grace period. Context-aware access uses access levels built from device and user attributes. OAuth controls let admins trust, limit, or block apps by scopes and verification status. Less secure app access and app passwords are legacy controls to phase out. Admin roles and least privilege, plus login challenges and session control, complete the picture.
Traps
A common trap is thinking 2SV enforcement applies instantly - enrolled users with a grace period keep access until it ends. Another is confusing context-aware access (controls access to Google apps by context) with endpoint management (controls the device). OAuth blocking by scope can break integrations; questions may ask which control stops a risky app without disabling all third-party access. Password policy length and reuse settings interact with 2SV. Security keys can be required for admins separately from general users. Trust rules and DLP are content controls, not authentication controls.
Rule of thumb
Enforce strongest controls on admins first, then roll out to OUs with a grace period. For a worked example, to block an unverified third-party app: use OAuth app access control to block that app or restrict its scopes, rather than disabling API access org-wide. Verify by checking the app's status and testing a sign-in.
Worked check
When a user is locked out after a policy change, check 2SV grace period, security key requirement, and login challenge settings in that order.