The 23-Minute Security Blind Spot: Why Google's API Key Revocation Leaves Doors Open

In the complex ecosystem of cloud security, authentication revocation stands as a critical safeguard against credential theft. Yet a recent investigation reveals a troubling vulnerability in Google's implementation: API keys continue to authenticate successfully for up to 23 minutes after deletion, leaving organizations exposed during what should be an immediate security response.

The research, conducted by security professionals, demonstrates a fundamental disconnect between user expectations and Google's authentication infrastructure. When a user deletes an API key through the Google Cloud Platform console, the interface confidently states "Once deleted, it can no longer be used to make API requests." This promise, however, remains unfulfilled for an uncomfortably long period, creating what the researchers term a "revocation window" during which attackers retain access to enabled APIs, including potentially sensitive services like Gemini.

Measuring the Invisible Window

To quantify this security blind spot, the researchers conducted a meticulous experiment across ten trials spanning two days. In each test, they created an API key, immediately deleted it, then initiated a sustained stream of 3-5 authenticated requests per second until all authentications failed consistently. This methodology aimed to test as many of Google's authentication servers as possible while respecting the platform's infrastructure limitations.

The results were concerning: the longest observed revocation window reached nearly 23 minutes, with the shortest at 8 minutes and a median around 16 minutes. More troubling than the duration was the unpredictability of the authentication success rate. In one trial, 79% of requests succeeded one minute after deletion, while another trial saw only 5% success in the same timeframe. This inconsistency means that both defenders and attackers face uncertainty about when a deleted key truly becomes invalid.

The chart plotting authentication success rates by minute across trials reveals no clean cutoff or predictable decay. Instead, access continues unevenly until it eventually stops—a behavior fundamentally at odds with the binary expectation of credential deletion.

Regional Inconsistencies Amplify the Problem

When extending the testing to different geographic regions, the researchers discovered additional layers of complexity. Running parallel trials from VMs in us-east1, europe-west1, and asia-southeast1 revealed significant regional disparities in authentication behavior.

Immediately after key deletion, success rates varied dramatically: in one trial, us-east1 saw 82% success while asia-southeast1 saw only 32%. Contrary to expectations, regions further from Google's US infrastructure appeared to pick up the deletion faster. Over the full revocation window, asia-southeast1 maintained a median success rate of 22%, compared to 49% for both us-east1 and europe-west1.

These regional differences suggest that Google's authentication infrastructure operates with complex routing, caching, or server affinity mechanisms that create uneven propagation of credential state changes across the global network. For security teams responding to credential leaks, this variability means the revocation window may behave differently depending on the geographic origin of attacker requests.

The Security Implications

A 23-minute revocation window represents a significant security exposure in several contexts:

1. Data Exfiltration: For API keys with access to sensitive services like Gemini, attackers can continue dumping uploaded files and exfiltrating cached conversations during the entire window.

2. Service Continuity: Attackers can maintain access to enabled APIs, potentially continuing malicious activities or pivoting to other services within the same project.

3. Incident Response Complications: Security teams responding to credential leaks must operate under the assumption that the compromised key remains active for up to 23 minutes after deletion, extending the potential blast radius of the breach.

4. JIT Credential Vulnerabilities: Services implementing Just-In-Time credential management must account for this extended window, fundamentally breaking the expected model of immediate credential invalidation.

Google's Perspective and Other Credential Types

When the researchers disclosed these findings to Google, the company closed the report as "won't fix," citing the eventually consistent nature of their distributed systems as a known property rather than a security issue. While Google does document eventual consistency for their IAM API, they do not specifically communicate this behavior for API keys.

Interestingly, the researchers found that other Google credential types exhibit much faster revocation:

• New Gemini API keys (AQ. prefix): ~1 minute
• Google Service Account keys: ~5 seconds

These alternatives suggest that faster revocation is technically feasible within Google's infrastructure, raising questions about why API keys maintain such a long revocation window compared to other credential types.

The researchers also discovered an additional complicating factor in the GCP console's monitoring capabilities. When examining authentication traffic after key deletion, they observed requests bundled under an "apikey:UNKNOWN" category. This grouping includes all requests made with any deleted API key, making it difficult for security teams to distinguish between active exploitation attempts and legitimate services using outdated credentials.

Navigating the Security Gap

Until Google addresses this architectural issue, organizations must implement compensating controls:

1. Operational Adjustment: Treat API key deletion as a 30-minute operation rather than an instantaneous action. Build incident response playbooks that account for this extended window.

2. Enhanced Monitoring: Regularly review API usage by credential in the GCP console, paying special attention to unexpected activity after key deletion.

3. Principle of Least Privilege: Minimize permissions assigned to API keys to reduce potential impact during the revocation window.

4. Short Credential Lifespans: Implement policies that require frequent rotation of API keys, reducing the window of opportunity for any single leaked credential.

The Fundamental Tension

This issue highlights a fundamental tension in distributed systems design: the tradeoff between consistency and availability. Google's eventually consistent model allows for global scalability and performance, but when applied to authentication, this tradeoff creates security vulnerabilities that directly contradict user expectations.

The AWS experience with a similar 4-second revocation delay demonstrates that even brief windows can be exploitable. As cloud services continue to evolve, the security community must advocate for authentication systems that prioritize immediate credential invalidation, recognizing that in security, eventual consistency is often an unacceptable compromise.

Looking Forward

The 23-minute revocation window for Google API keys represents more than a technical curiosity—it's a systemic security issue that affects thousands of organizations relying on Google Cloud services. Until Google addresses this architectural decision, security teams must adapt their practices to account for this extended exposure period.

As cloud providers continue to scale their infrastructure, the security community must demand that authentication systems operate with principles of immediate invalidation, recognizing that the gap between user expectations and technical implementation can create dangerous security blind spots. The eventual consistency model that works well for data updates becomes a liability when applied to credential revocation, where every additional second of validity extends the potential damage from compromised credentials.

In the meantime, organizations should review their API key management practices, implement stricter monitoring, and adjust their incident response procedures to account for this extended revocation window. The security of cloud services depends not just on the providers' architectures, but on the informed practices of those who build upon them.