On May 15, 2026, Google announced a useful safety net for Google Workspace admins: a single default Context-Aware Access policy that can apply to all SAML apps.
That matters because SAML and OIDC apps are often where sensitive business systems live. If one of those apps is outside your Context-Aware Access coverage, users may be able to reach it without the device, location, or network checks you expect.
Why this control matters
Context-Aware Access is Google Workspace's way to say, "Do not let someone into this app unless the request matches the conditions we trust." Those conditions can include the user's IP range, device posture, location, or other access levels.
Before this change, admins had to assign CAA policies to SAML and OIDC apps individually. That works, but it is easy to miss an app. A default policy reduces that risk by catching SAML apps that do not have their own app-specific CAA assignment.
The practical risk
A tenant can have strong CAA rules for core Google services and still leave third-party SAML or OIDC apps exposed. The new SAML default policy helps close that gap, but only after an admin turns it on.
The hard part: Google does not expose the toggle through a policy API
The cleanest audit would read the policy directly and report whether the default SAML CAA policy is enabled. Today, that direct signal is not available through a public Workspace policy API.
We tested the likely places: Cloud Identity Policy API in both v1 and v1beta1, plus Access Context Manager. Access Context Manager exposes the building blocks of CAA, such as access levels and service perimeters, but it does not expose the app-assignment toggle we need for ADD-40. The older OIDC check, ADD-20, has the same limitation.
What this means for auditing
We cannot honestly say "enabled" or "disabled" by reading a configuration endpoint. Instead, we look for evidence in the audit logs.
The better signal: audit logs
Audit logs do not show the toggle directly, but they do answer two important questions:
1. Are SAML or OIDC apps actually being used?
If no apps in that category were used during the audit window, there is nothing meaningful for the default policy to protect in that period.
2. Has CAA blocked access to those apps?
A CAA denial is strong evidence that the policy is active and enforcing for that class of app.
Argus now uses three Reports API log streams to build that picture:
Token audit logs
applicationName=token shows OAuth and OIDC grants. Argus filters for third-party OIDC clients and excludes Google's own apps.
Login audit logs
applicationName=login shows SAML logins when login_type=saml. This gives Argus a working list of SAML SSO apps used during the audit window.
Context-Aware Access audit logs
applicationName=context_aware_access shows ACCESS_DENY_EVENT entries. Even one matching denial proves CAA is enforcing.
How ADD-20 and ADD-40 decide what to report
Both checks now follow the same simple decision tree. ADD-20 applies it to OIDC apps. ADD-40 applies it to SAML apps.
Build the app inventory
Argus counts distinct third-party apps used during the audit window.
If the count is zero, the result is NOT_APPLICABLE. That means Argus did not see recent usage for that app type.
Look for enforcement evidence
Argus checks CAA audit logs for matching ACCESS_DENY_EVENT entries.
If at least one denial is found, the result is PASS. CAA is provably enforcing for that app class.
Report uncertainty clearly
If apps exist but no matching denial was seen, the result is MANUAL.
This does not mean the policy is off. It means Argus saw apps in use, but did not see a CAA block during the audit window. The result includes the app inventory so an admin knows exactly what to verify.
Example output from a live tenant
On an Enterprise Standard test tenant, the updated checks produced a more useful result than the old blanket "review manually" response:
# ADD-20 — third-party OIDC apps were detected
ADD-20 status=MANUAL
10 third-party OIDC app(s) detected (ArgusSec, Argussec,
CapCut-Web, Curier rapid, GAM...) but no CAA
ACCESS_DENY_EVENT was logged in the window. Absence of
denials does not prove CAA is disabled — verify the
policy assignment in Admin console > Security >
Context-Aware Access.
# ADD-40 — no SAML logins were detected
ADD-40 status=NOT_APPLICABLE
No SAML SSO logins detected in the audit-log window;
the default-CAA-for-SAML control has nothing to apply to.
On a tenant with active SAML apps, ADD-40 would return MANUAL if apps were detected but no denial events were found, or PASS if CAA denial events confirmed enforcement. As the audit data improves, the check can move from uncertainty to evidence automatically.
Important caveats
The new checks are more useful, but they still avoid pretending the logs can prove something they cannot. Here is what admins should keep in mind:
"Detected" means used during the audit window
An app that is configured but unused during the lookback period will not appear in the logs. In that case, NOT_APPLICABLE really means "no recent usage detected."
Monitor mode does not create denial events
ACCESS_DENY_EVENT is created when CAA actively blocks access. A monitor-only policy may be configured correctly but still produce no denial events.
Direct policy evaluation will be better when Google exposes it
If Google later publishes an API surface for the default SAML CAA toggle, ADD-40 can move from log-based inference to direct policy evaluation.
What admins should do now
- 1 Re-run your Argus audit. Check the new ADD-40 result for SAML and the improved ADD-20 result for OIDC.
- 2 If ADD-40 is NOT_APPLICABLE, Argus did not see SAML SSO usage in the audit window. There may be nothing to fix right now, but confirm that matches your environment.
- 3 If ADD-40 is MANUAL, SAML apps are being used. Go to Admin console > Security > Context-Aware Access > General settings and verify the default SAML CAA policy.
- 4 If ADD-20 is MANUAL, review the listed third-party OIDC apps and confirm they are covered by your CAA policy.
Argus now ships 200 checks. ADD-20 and ADD-40 are only a small part of the catalog, but they cover one of the most important Zero Trust controls in Google Workspace. The new SAML default policy is the kind of admin setting that can quietly raise the security floor for an entire organization.