TL;DR: Three 2022 breaches show how exposed credentials, post-employment access, and phishing can still bypass enterprise controls, according to Axiad. The common failure is not just user error but weak identity governance over third parties, leavers, and authentication paths.
At a glance
What this is: This is Axiad’s analysis of three 2022 breach patterns showing how exposed credentials, leaver access, and phishing can defeat otherwise mature identity controls.
Why it matters: It matters because identity teams have to govern third-party access, offboarding, and authentication paths as one control system, not three separate problems.
Context
The core issue is not simply that passwords were stolen. It is that identity controls failed at the points where access was granted, retained, or validated, allowing a subcontractor, a former employee, or a phishing victim to become the path into sensitive systems.
For identity and access management teams, the article is really about governance drift across the access lifecycle. Third-party credentials, leaver access, and phishing-resistant authentication are all identity problems, but each one fails in a different place and demands a different control response.
Key questions
Q: What breaks when third-party credentials are published in source code?
A: A public code leak becomes an access event when secrets remain valid after exposure. The breach risk is not limited to the repository. It extends to whatever server, cloud account, or API the secret unlocks. Teams need secret scanning, rapid revocation, and separate handling for third-party code contributions.
Q: Why do ex-employee accounts still create breach risk after offboarding?
A: Because offboarding is only effective when entitlements, report access, and authentication paths are removed together. If a former employee can still reach sensitive data after leaving, the organisation has left a live identity path behind, which turns a routine leaver event into a data exposure problem.
Q: How can organisations tell whether authentication is actually phishing-resistant?
A: Authentication is phishing-resistant when a stolen code, password, or proxy cannot be reused to satisfy the login flow. The control should bind the credential to the device or verifier, remove shared secrets from the critical path, and avoid fallback steps that reintroduce phishable factors.
Q: Should identity teams prioritise offboarding or phishing resistance first?
A: If the organisation has repeated leaver-access or third-party access problems, offboarding and entitlement control usually need immediate attention. If the dominant risk is credential theft through social engineering, phishing-resistant authentication should move up the list. The right priority depends on which identity path is most likely to fail first.
Technical breakdown
How exposed credentials become a third-party entry point
Public code repositories and other shared development surfaces can turn a small credential mistake into a live access path. In the Toyota example, a subcontractor published source code credentials on GitHub, and those credentials later enabled access to a company server. The technical problem is not just leakage. It is that the leaked secret remained valid long enough to be abused, which shows why credential exposure and credential lifetime have to be governed together.
Practical implication: treat third-party code repositories as credential distribution channels and remove standing access paths as soon as exposure is detected.
Why leaver access becomes a governance failure
Former employees should not retain the ability to access production reports or customer data after employment ends, yet the Cash App case shows how that boundary can break in practice. The failure is usually not one control alone, but weak offboarding, stale entitlements, and insufficient review of who still has access to sensitive report views. In identity terms, the access lifecycle continued after the employment relationship ended.
Practical implication: align offboarding, entitlement review, and report-level access control so terminated users lose access before their status changes become exploitable.
Why phishing still succeeds when authentication is only partly hardened
Cloudflare’s case shows that phishing can still capture usernames and passwords even when an organisation uses stronger sign-in controls. The technical distinction matters: attackers did obtain credentials, but hardware key enforcement blocked them from turning those credentials into usable sessions. That is the difference between credential capture and authentication compromise, and it is why password-only or weakly enforced MFA paths remain high risk.
Practical implication: enforce phishing-resistant authentication on every privileged and workforce path where stolen credentials would otherwise be enough to authenticate.
Threat narrative
Attacker objective: The objective was to turn valid identity material into unauthorized access to company systems and customer information.
- Entry began when a third-party contractor published source code credentials on GitHub and an attacker later used those credentials to reach a Toyota server.
- Credential abuse followed when a former employee retained access to customer reports after employment ended and downloaded data they should no longer have been able to reach.
- Phishing succeeded when SMS messages impersonating an Okta login page captured employee usernames and passwords, creating an attempted credential-harvest path.
- Impact varied by case, but the common outcome was unauthorized access to customer data or an attempted path into internal systems through identity failure rather than malware.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Third-party credential exposure is a lifecycle failure, not a one-off mistake: The Toyota case shows that a subcontractor’s public GitHub upload became a live enterprise risk because the credential stayed usable long after exposure. That is not just secret leakage. It is a breakdown in ownership, inventory, and revocation discipline across the extended identity supply chain. Practitioners should read this as a warning that third-party access is only as safe as its offboarding and rotation controls.
Leaver access reveals whether identity governance actually ends when employment ends: Cash App’s breach pattern demonstrates that termination is a process boundary, not an administrative note. If an ex-employee can still reach customer reports, then access reviews, entitlement expiry, and offboarding are not aligned. The breach worked because the organisation’s governance assumption outlived the employment relationship, and that is a structural failure of lifecycle control.
Phishing-resistant authentication is now a containment control, not just a login control: Cloudflare’s example shows that credentials can be harvested even when the attacker never reaches the protected system. Hardware-key enforcement prevented the stolen usernames and passwords from becoming valid sessions, which means authentication policy determined breach impact. This is why identity teams must treat phishing-resistant sign-in as part of incident containment, not just user convenience.
Identity attack surface is now distributed across contractors, leavers, and sign-in paths: These breaches are not separate stories. They are one governance problem expressed through three different identity states. The common lesson is that control failure rarely sits only in authentication or only in access management; it sits where those controls stop talking to each other. Practitioners should govern the identity perimeter as a continuous lifecycle, not a set of isolated checkpoints.
What this signals
Identity governance has to follow the access lifecycle, not just the sign-in event: These breaches show that identity failure can begin long before authentication and continue after employment ends. The practical response is to govern who can create, store, and reuse credentials across third parties, internal users, and report consumers, rather than treating each access path as an isolated control.
Leaver controls are only as strong as the systems that inherit them: If report exports, customer data views, or subcontractor repositories are left outside the offboarding process, the organisation still has a standing identity risk. That is why lifecycle governance must include non-obvious assets such as shared code repositories, analytics reports, and delegated admin paths.
For practitioners
- Review third-party credential exposure paths Inventory where contractors and subcontractors can place source code, keys, and tokens, then revoke any access that is not explicitly needed for the current engagement.
- Tighten offboarding for report access Map every privileged report, export path, and customer data view to a leaver revocation step so terminated users lose access before account closure is complete.
- Enforce phishing-resistant sign-in Require hardware-key or equivalent phishing-resistant authentication for the accounts that would cause material harm if credentials were captured.
- Validate access key rotation after exposure When credentials appear in public code or shared tooling, rotate the affected keys, remove any unnecessary server access, and confirm that the old secret no longer authenticates.
Key takeaways
- These 2022 breaches show that identity failures can originate in third-party credential handling, offboarding gaps, and phishing, even when organisations already have security controls in place.
- The evidence spans exposed contractor credentials, retained post-employment access, and credential-harvesting SMS attacks, which together show that identity risk is distributed across the full access lifecycle.
- The control gap is lifecycle governance. Revocation, entitlement removal, and phishing-resistant authentication need to operate as one programme if teams want to reduce breach impact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Cash App shows a leaver retaining access after employment ended. |
| NHI-03 — Vulnerable Third-Party NHI | Toyota shows third-party credentials becoming a live enterprise entry point. | |
| NHI-04 — Insecure Authentication | Cloudflare shows credential capture still matters when sign-in controls are not phishing-resistant. | |
| Recommendation — Align offboarding workflows to revoke every account and report path when employment ends. Inventory third-party identities and require rapid revocation when credentials are exposed. Enforce phishing-resistant authentication on accounts whose compromise would be material. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article centres on credential theft and use for unauthorized access. |
| Recommendation — Map exposed-credential and phishing paths to credential access and lateral movement detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about identities retaining or gaining access they should not have. |
| Recommendation — Review entitlements and authorization paths so access ends when it should. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The cases show why secret rotation and authenticator lifecycle are central controls. |
| Recommendation — Apply authenticator management to rotate or revoke credentials as soon as exposure is identified. | ||
Key terms
- Third-Party NHI: Third-Party NHI is a non-human identity owned or operated by an external organization, partner, contractor, or supplier. It includes service accounts, API keys, certificates, tokens, and automated agents that access systems outside the primary enterprise boundary. Governance must cover issuance, scope, monitoring, revocation, and contractual accountability.
- Offboarding: Offboarding is the controlled retirement of a workload, service account, token, certificate, or other non-human identity when it is no longer needed. It includes revoking credentials, removing permissions, and verifying that no residual trust path remains available to attackers.
- Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
- Authenticator Lifecycle Management: Authenticator lifecycle management is the governance of a credential from issuance to renewal, replacement, and retirement. For human identity programmes, it ensures that keys, smart cards, and certificates stay tied to the right user and are removed when the user, role, or device is no longer trusted.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org