Identity & Access Monitoring

MFA Status Admin Roles Sign-in History OAuth Grants Google Workspace

Why Identity Is the Primary Attack Surface

Credential-based attacks — phishing for passwords, password spraying, session token theft — require no malware and leave no endpoint artifact until an attacker is already inside the environment. The initial access step is an authentication event that looks identical to a legitimate login. The only way to distinguish it is context: does this login match the user's established pattern? Is the device familiar? Has this IP appeared before?

Identity monitoring answers those questions continuously, for every authentication event in the environment. It does not require endpoint agents or network sensors. The Admin SDK and Alert Center give ARIA direct access to authentication events, admin console actions, and OAuth grant records for every user in the Workspace tenant.

MFA Status

ARIA surfaces users who do not have two-factor authentication enabled on their Google Workspace accounts. MFA enrollment status is available through the Workspace Admin SDK directory API. Accounts without MFA are significantly more susceptible to credential theft — a phished password is sufficient for account takeover with no further exploitation required.

ARIA also monitors for MFA bypass events: when a user authenticates without their second factor in a context where one would normally be expected. Alert Center fires on suspicious login events that include bypassed or absent MFA challenges, and ARIA investigates these for context before escalating confirmed anomalies.

Admin Role Changes

Changes to administrative privileges in Google Workspace — assigning super admin access, creating a new admin role, granting delegated admin permissions — are high-risk events that deserve immediate investigation when they occur outside of an expected provisioning workflow. An attacker who has compromised a standard user account will often attempt to escalate to admin access to establish persistence and broaden their reach.

Super Admin Grant

ARIA fires on any event where super admin privileges are assigned to an account. Super admins have unrestricted access to the Workspace environment — every user's data, all settings, billing, and domain management. There is rarely a legitimate reason to grant super admin access without prior planning.

Role Assignment Outside Business Hours

Admin console actions that occur outside of the organization's normal operational hours — late night, weekends, or holidays — are worth investigating regardless of which account performed them. Attackers who compromise an admin account prefer to act when the change is least likely to be noticed immediately.

Delegated Admin Created

Delegated admin roles with specific permissions — account management, group management, reporting — can be created to grant limited admin access. ARIA monitors the creation of new delegated admin accounts and correlates them against any recent suspicious activity involving the creating account.

Sign-in History and Anomalous Logins

Google Workspace Alert Center fires on login events that its own heuristics flag as suspicious: logins from IPs associated with known threat infrastructure, login attempts from geographic locations far removed from the user's established pattern, or logins from devices not previously seen on the account. ARIA receives these alerts and adds investigation context:

Whether the IP appears on any threat intelligence feeds ARIA monitors
Whether the same IP has triggered alerts for other users in the tenant — a sign of a targeted credential spray
What actions the account took after login — which applications were accessed, whether admin console actions followed
Whether the login correlates with a phishing alert for the same user in the same timeframe

A login from an unfamiliar country followed by immediate admin console access is a confirmed escalation. A login from a new IP with no subsequent anomalous activity and a known VPN provider may close as low-risk — with the investigation logic recorded.

OAuth Grants and Third-Party App Access

When a Workspace user authorizes a third-party application — a productivity tool, a file converter, a calendar integration — that application receives an OAuth token granting it access to the user's data. The scope of that access is determined at authorization time and, unless the token is explicitly revoked, persists indefinitely. Applications that are no longer in use continue to hold access grants that represent an ongoing exposure.

ARIA monitors OAuth grant events from the Workspace Admin SDK: new grants, grants with broad scopes (particularly those requesting access to Gmail or Drive contents), and grants from applications that have not been reviewed or approved at the organizational level. ARIA also surfaces grants to applications that subsequently appear on threat intelligence feeds — a third-party application compromised after the fact is an access path that looks legitimate until it is not.

Revocation of OAuth tokens for specific applications is a containment action ARIA can propose and a security engineer can approve — removing the application's access across all users in the tenant who granted it.

Related Use Cases

Email SecurityPhishing and BEC — the initial access vector

Cloud ActivityWhat a compromised account does next

Endpoint DetectionCredential theft on the device itself

SaaS CompaniesSOC 2 access control and user management evidence

Common Questions

How does ARIA get access to Google Workspace sign-in events?

ARIA uses a service account with read-only access to the Google Workspace Admin SDK and Alert Center APIs. The service account is provisioned with the minimum necessary permission scopes: Admin SDK Reports (for audit log and login activity), Alert Center viewer, and Directory (for user and group data including MFA enrollment status). ARIA never has write access to Workspace settings, users, or mail; any action that modifies the environment requires explicit security engineer approval and is executed through a separate, purpose-limited API call.

Can ARIA detect when someone's credentials have been phished before they're used?

Not before use — credential theft that occurs outside the Workspace environment (on a phishing page, via infostealer malware) is not visible to ARIA until the stolen credentials are used for an authentication attempt. What ARIA can do is detect the phishing attempt via Alert Center (if Google's classifier identifies the message), and if successful authentication with anomalous characteristics follows, correlate those two events into a confirmed incident. It also monitors for the pre-authentication indicators that precede credential-based compromise: suspicious sign-in attempts, unusual account enumeration patterns, and Alert Center government-backed attack warnings.

Does ARIA enforce MFA, or just report on it?

ARIA surfaces MFA gaps and anomalies — it does not enforce MFA policy. Enforcing MFA in Google Workspace is an admin console setting that applies organization-wide or per organizational unit. ARIA's role is to identify accounts where MFA is not enabled and flag authentication events where MFA was bypassed or absent, so a security engineer can review and either enforce the policy or investigate the specific account. Enabling MFA enforcement in Workspace is something ARIA will recommend but not execute without explicit approval.