Google published a consumer security post on 30 October 2026 asking a simple question: when did you last check who, or what, has access to your Gmail inbox? The answer for most people is never. The answer for most organisations is worse.

The post is short, sensible and written for individuals. Read as an enterprise document, it names a problem nobody has finished solving.

What Google actually published

The post points readers to Google Security Checkup and lists three steps: review signed-in devices, remove old third-party app access, and confirm recovery information.

That is the entire instruction set. It is good advice, and it takes about two minutes because a consumer typically holds a handful of grants, most of them recognisable.

Two things the post does not do. It does not describe administrative tooling for an organisation, and it does not quantify how long a revoked grant takes to stop working across connected systems. Neither is asserted here, because the retrieved text does not establish either.

Why the second step is not a two-minute problem

The middle instruction is the difficult one. Removing old third-party app access assumes you can see the list, recognise the names and judge which are still needed.

In a business, the list is longer, the names are less familiar, and the person best placed to judge is often no longer employed there.

Three failure modes recur.

  • The grant outlives the grantor. A token was approved by an individual. Offboarding disables the account. Whether the token survives that is a separate question, and often an untested one.
  • Nobody owns the grant. Access was approved for a project that ended. No one is accountable for the permission, so no one reviews it.
  • The scope was never recorded. The approval captured a decision to allow access, not which mailboxes, folders or fields that access reaches.

None of these is a phishing failure. They are lifecycle failures, and they do not appear in a password audit.

The standards framing, and its limit

NIST's Cybersecurity Framework is voluntary and organised around core functions including identify, protect, detect, respond and recover. Placed beside the Gmail checkup, it relocates the problem.

Listing application grants is an identify activity. Revoking them is a protect activity. Noticing that a revocation failed is detect. Most organisations are competent at the middle one and thin on the other two.

CISA's public awareness guidance returns repeatedly to credentials: strong passwords, multi-factor authentication, phishing awareness. That guidance is correct and it addresses authentication strength. Grant sprawl is an authorisation breadth problem, and strength does not shrink breadth.

Preference is not permission

On the same day, OpenAI described a different kind of control: it said it will honour a shared robots.txt signal so website operators can communicate AI training preferences to participating providers.

Both items are voluntary mechanisms aimed at a defined group. Both are weaker than an enforced rule. An operator who assumes every crawler respects a signal is assuming more than the announcement says, just as an administrator who assumes account disablement revoked every token is assuming more than the console shows.

Neither assumption is unreasonable. Both need testing rather than believing.

What remains unknown

  • No revocation timing. How quickly a removed grant stops working across dependent systems is not established in the material reviewed.
  • No administrative scope. Google's post is consumer guidance; organisation-level tooling and its audit depth are not described there.
  • No prevalence data. No figure on how many enterprise grants are stale is asserted, because none was reviewed.
  • No participant list. Which providers honour the training-preference signal, and from when, is likewise unestablished.

Five questions to put to your own environment

  • Can you produce the list? Every third-party application grant touching mail, files or identity, with the date it was approved.
  • Who owns each one? A named person as of today, not the person who originally requested it.
  • What does it reach? The recorded scope, not the vendor's marketing description of it.
  • What happens at offboarding? Whether token revocation is part of the process or hoped for as a side effect.
  • Can you prove revocation works? A tested result after disabling an account, not an assumption drawn from the admin interface.

The fifth is the one that changes behaviour, because it converts a belief into evidence.

A phased plan that produces evidence

  • Phase zero, export the grants. Do not remediate. Just produce the list and count it. Most teams are surprised by the total and by how many they cannot attribute.
  • Phase one, assign an owner to every grant. Where no owner can be found, the grant is stale by default and gets queued for removal.
  • Phase two, test one revocation end to end. Choose a low-risk grant, revoke it, and confirm from the outside that the access actually stopped.
  • Phase three, fold it into offboarding. Add token and grant revocation to the leaver checklist, and re-test quarterly rather than annually.

Four indicators worth baselining

Grant inventory coverage: the share of third-party grants with a named current owner. Unattributed grant count: permissions nobody can explain. Revocation latency: measured time from revoke to confirmed denial. Offboarding completeness: the share of departures where every grant was verified closed.

Baseline all four in your own environment. A defensible improvement claim comes from your own before and after, not from a vendor benchmark.

Why this matters beyond email

Three observations, offered as analysis rather than reporting.

First, identity is the integration surface now. Every connected application is a decision about who may read, change and approve, and those decisions accumulate faster than any review cycle.

Second, the consumer framing is a useful diagnostic precisely because it is simple. Three steps is the whole instruction. An organisation that cannot produce the same three answers in a week has found its gap.

Third, voluntary mechanisms reward the organisations that know their own exposure. You cannot express a preference about a crawler you did not know could reach you, or revoke a grant you never inventoried.

Evidence notes and limits

Evidence was reviewed through 15:00 UTC on 31 October 2026. Four sources support the factual claims above: the Google Security Checkup post of 30 October 2026; the OpenAI post of the same date on the shared training-preference signal; the NIST Cybersecurity Framework, a voluntary framework organised around core functions including identify, protect, detect, respond and recover; and CISA's public secure-practice guidance on passwords, multi-factor authentication and phishing awareness.

All four are vendor or government publications. None is an independent evaluation of any product or platform. Google's post was described at the level of its published text; its administrative capabilities and revocation behaviour are explicitly not characterised, because they were not established here.

No customer results, adoption figures, prevalence statistics, financial results or stock movements are asserted, and no partnership or certification is claimed. The five questions, phased plan and four indicators are analysis and suggested method, not a tested protocol.