Executive summary
Security programmes are generally good at watching access that looks like access: employee accounts, admin credentials, privileged roles under review at each access recertification cycle. This paper is about the category that falls outside that habit - access that continues to exist without anyone having an ongoing reason to look at it. CrowdSec's own postmortem, published 18 September, is candid about the first example: a former developer's GitHub token stayed live because "we parted on good terms with our developer, and he wanted to finalize some work," and that same token was used to copy roughly 170 private repositories on 22 May, eleven days after the account had already been compromised through May's TanStack npm supply chain attack. The theft wasn't discovered until the stolen code surfaced on a cybercrime forum on 16 September - four months later. Manchester Airports Group's breach, disclosed in the same window, had an even longer invisible-access window: three server-side API keys, intended only to log email-open and click events, sat readable in public-facing JavaScript for more than four years, carrying read/write access to the group's entire customer database the whole time, before they were used to access 8.8 million people's records. And CVE-2026-58704, the Pixel modem flaw Google patched and CISA added to its exploited-vulnerabilities catalog on 16 September, is a different but related failure mode - an attack surface so invisible to the user that no amount of security awareness training could have flagged it, because there was never anything to click.
What ties these together isn't sector, cause or even technical category - it's that each one describes access, or an access path, that existed for months or years without a trigger that would have brought it back under review. A credential doesn't announce that its owner has left. An API key doesn't announce that it was scoped far more broadly than its stated purpose. And a hardware component doesn't announce that its permission logic has a bypass. This paper sets out a framework for finding and governing that category deliberately, built around the premise that the access most worth worrying about is the access nobody currently has a reason to be looking at.
1. Access doesn't expire just because its purpose did
CrowdSec's access decision wasn't reckless in the way that phrase usually implies - it was a reasonable-sounding exception, made in good faith, for a specific and bounded piece of unfinished work. The failure wasn't the exception itself; it was that the exception had no expiry date and no owner checking whether the work it was granted for had actually finished. CrowdSec's own report doesn't suggest anyone was actively monitoring that account after it was granted its extension - it simply continued to exist, fully privileged, until an unrelated supply chain attack against a completely different project compromised the machine it was sitting on. The lesson isn't "never make exceptions" - unfinished handover work is a real and common situation. It's that an access exception needs the same lifecycle discipline as the access it's extending: a date it expires, a named owner who has to actively renew it, and a default of automatic revocation if nobody does.
2. Purpose-scoped credentials drift silently toward broad access
Manchester Airports Group's API keys were, by design, meant to do one narrow thing - record that a marketing email had been opened or clicked. What they actually carried was read/write access to the group's entire customer database, a scope mismatch that existed from the day the keys were issued and went unnoticed for over four years because nothing about normal operation would have surfaced it. A key that works correctly for its stated purpose gives no outward sign that it's also capable of much more, and unless someone specifically audits scope against purpose - rather than simply confirming the integration still functions - that gap has no reason to ever come to light. The Pixel modem bug shares the same shape at a different layer: a permission check that was supposed to gate escalation had a logic error that let it through anyway, and normal operation of the modem gave no indication that check was broken until someone deliberately tested it, or until an attacker found it first.
3. Discovery windows are measured in months, not days
CrowdSec's theft happened on 22 May and wasn't discovered until 16 September - just short of four months. Manchester Airports Group's keys were exposed for more than four years before they were used against the organisation. In both cases, the gap between the access existing and someone noticing it wasn't a failure of incident response - the response, once triggered, was fast in both instances. It was that nothing in the organisation's normal operating rhythm was ever going to surface the problem on its own; discovery depended entirely on an external event - stolen code appearing on a forum, a breach notification - happening to occur. A governance model that only finds this category of exposure when something else forces it into view is, by definition, not finding most of it, because most invisible access never gets used in a way that produces that kind of external trigger at all.
4. Some invisible access can't be caught by watching for behaviour
The first two stories are ultimately about credentials nobody was watching. CVE-2026-58704 is different, and arguably harder: a zero-click exploit path where the attacker doesn't need to generate any user-visible behaviour to succeed at all - no phishing email to report, no suspicious login to flag, nothing for even a well-trained, security-conscious user to notice. Reporting on the flaw notes Google's own description gives no indication of how the confirmed "limited, targeted" exploitation actually occurred, which is consistent with this category of bug - modem-level, zero-click flaws on flagship devices are the profile associated with spyware-grade tooling built specifically to leave nothing for the target to notice. Where the first two failures are about governance discipline, this one is a reminder that some invisible access simply can't be caught downstream of the vulnerability at all - the only real defence is patch-level compliance verified against the specific CVE, faster than the exploitation window.
Practical framework checklist
The following translates the four findings above into decisions a security or identity governance programme can act on now.
- Require every offboarding access exception to carry an explicit expiry date and a named internal owner who must actively renew it - a departing employee's access defaults to revoked, and any extension is a deliberate, time-boxed decision rather than an informal courtesy.
- Audit API key and service credential scope against stated purpose on a fixed schedule, not just at issuance - a key that logs email clicks has no legitimate reason to retain database write access years later, and only a deliberate scope review will ever catch that drift.
- Build discovery mechanisms that don't depend on an external trigger - periodic access recertification, credential-age reporting and dormant-account detection all surface this category of risk without waiting for stolen data to appear on a forum first.
- Track patch-level compliance against specific, named CVEs for mobile and endpoint devices, not just "latest update installed" status, for any device profile that plausibly represents a high-value target for zero-click, spyware-grade exploitation.
- Treat "we parted on good terms" or "it's only used for one narrow thing" as a prompt for extra scrutiny, not a reason to relax it - both are exactly the reasoning that let CrowdSec's and Manchester Airports Group's exposures go unmonitored for as long as they did.
- Scope every incident response runbook to assume the discovery date and the breach date are different, and investigate back to the last point the credential or access path was verifiably still under active control.
Risks and how to manage them
The most common failure mode is treating access governance as an event-driven process - something that happens at onboarding, offboarding and periodic recertification - rather than a standing state that needs monitoring between those events. CrowdSec's exception and Manchester Airports Group's mis-scoped keys both survived comfortably inside the gaps between scheduled reviews. A second failure mode is assuming that a credential's stated purpose accurately describes its actual capability; nothing about normal, correctly functioning use of an email-tracking key would ever have revealed its database access on its own. A third is assuming security awareness training covers the full range of what an organisation needs defended against - the Pixel modem flaw is a direct counterexample, a vulnerability class where there is nothing for even the most vigilant user to notice or report.
Conclusion
None of the three stories in this paper involved a sophisticated attack in the way that phrase usually implies. A courtesy access extension, a credential scoped more broadly than its purpose required, and a permission-check logic error are all, individually, familiar and unglamorous categories of problem - which is precisely why they survive so long unexamined. What ties them together is that each one was invisible by default, not through any active concealment, simply because nothing about an organisation's normal operating rhythm was ever going to bring it back into view. A governance programme that puts expiry dates and named owners on every access exception, audits credential scope against purpose on a fixed schedule rather than only at issuance, and assumes a breach's discovery date tells it nothing about the breach's actual date, will find this category of exposure before an external event forces it into view. For a facilitated review of the access your organisation has stopped actively watching, contact sales@halfteck.com.