On 22 July 2026, Origin Energy told the market it was investigating a potential security incident. Six days later the picture sharpened: the information of roughly 900,000 current and former customers had been accessed. Australia's largest energy retailer, with 4.8 million customer accounts and about $8.5 billion in annual revenue, had a problem. A later review added about 60 complete bank account numbers, 100 ID document numbers and 15,000 government concession numbers.
The person claiming responsibility first made contact on 2 July. Origin went public on 22 July, three weeks later. The reported mechanism was a credential that outlived its purpose on the Kraken customer-management platform, an unremarkable process failure with consequences far beyond the cause. This page is the hub for a four-part series on what happened, why it keeps happening, and how you check your own exposure.
In this series
- What Happened in the Origin Energy Customer Data Breach
- Why Unrevoked Credentials and Orphaned Accounts Keep Causing Breaches
- Credential Lifecycle Management and Why Offboarding Audits Matter
- Standing Privilege, PAM and Just-in-Time Access Explained
What actually happened in the Origin Energy data breach?
Roughly 900,000 current and former Origin Energy customers had personal information accessed, with a later review adding about 60 complete bank account numbers, 100 identity document numbers and 15,000 government concession numbers. Origin was first contacted on 2 July and went public on 22 July, a three-week disclosure gap. Reporting points to unrevoked credentials on the Kraken customer-management platform, not a novel exploit.
This is one of the largest known incidents for an Australian energy retailer. Investigators linked the access to a former Accenture employee at a Manila call centre serving Origin, and the matter remains under an open AFP investigation. What Origin did not release is just as telling: no indicators of compromise, no CVE, no ATT&CK mapping. With an unrevoked credential there is nothing to patch; the fix is a process change. The executive bonus clawback, which cost CEO Frank Calabria $357,000 and other executives $607,000, rounds out the picture. For the full timeline, read what actually happened. Why that credential stayed live comes next.
Cluster Link: What Happened in the Origin Energy Customer Data Breach
Why do unrevoked credentials and orphaned accounts keep causing breaches?
Access survives offboarding when a credential is not revoked, when a contractor's access outlasts an engagement, or when an account loses its owner but keeps working. Orphaned accounts, ghost credentials, privilege creep and non-human identities accumulate, look legitimate in logs, and are cheap to exploit. Compromise is usually detected only after data has moved. Negligence, not malice, is the usual driver.
The blind spot that bit Origin is third-party and contractor access: a vendor-operated platform, an outsourced call centre, and a credential that nobody's offboarding checklist reached. Wing Security research puts the share of businesses with former employees still holding access at 63%, and the Ponemon Institute, the Verizon DBIR (2026) and IBM X-Force each find most insider breaches are non-malicious. The vendor and contractor blind spot behind all of this is why credentials outlive the need worth internalising. Standing privilege is the root condition that makes unrevoked access dangerous, covered in the access-model section below.
Cluster Link: Why Unrevoked Credentials and Orphaned Accounts Keep Causing Breaches
What is credential lifecycle management, and why does it matter now?
Credential lifecycle management governs every credential from creation through change to removal, so none keeps granting access after its purpose ends. The Origin case shows the leaver stage is where value and risk concentrate: a credential that should have died when employment ended stayed live on a third-party platform. Offboarding gaps are among the most common findings in ISO 27001 and NIST-aligned audits, a measurable, fixable exposure.
Think of a credential as having a life: it is born, it gets used, it changes, and it must die. The joiner/mover/leaver (JML) procedure is the skeleton, and the leaver stage is the one everyone rushes, spanning manual steps, distributed systems and third parties. The question is whether you can prove access died everywhere, including on the vendor's platform. ISO 27001 Control 6.5 and NIST SP 800-53 PS-04 and PS-05 point at the same idea: access must end when the relationship that justified it ends. how to assess your offboarding process turns that into an evaluation lens, tying back to the orphaned credentials above.
Cluster Link: Credential Lifecycle Management and Why Offboarding Audits Matter
How do standing privilege and just-in-time access reshape your exposure?
Standing privilege means elevated access is always on, so one stolen credential can reach every system it was authorised for. Just-in-time access provisions privilege only for a task, for a bounded window, then revokes it automatically. The distinction matters because it shrinks both the blast radius and the window in which unrevoked access can be abused. PAM governs how privileged access is brokered and monitored; lifecycle management governs whether an identity should hold access at all.
The clearest framing is scope versus duration. Least privilege limits how much access an identity holds, while zero standing privileges adds a duration dimension by removing always-on elevated access. The duration piece is what closes the window that unrevoked access exploits. A stolen credential with standing privilege is a key that keeps working; with just-in-time access it dissolves after the job is done. how just-in-time access removes standing privilege unpacks that distinction at the model level, including break-glass access as the governed exception.
Cluster Link: Standing Privilege, PAM and Just-in-Time Access Explained
Resource hub
The incident and its root cause
- What Happened in the Origin Energy Customer Data Breach (6 min read): the full timeline, the escalating figures and the three-week disclosure gap, plus why the missing IOCs and CVE are instructive. Start here if you are new.
- Why Unrevoked Credentials and Orphaned Accounts Keep Causing Breaches (6 min read): orphaned accounts, ghost credentials, privilege creep, non-human identities and the negligence pattern.
The discipline and the access model
- Credential Lifecycle Management and Why Offboarding Audits Matter (5 min read): the joiner/mover/leaver discipline, ISO 27001 Control 6.5 and NIST PS-04/PS-05, and how to assess your offboarding.
- Standing Privilege, PAM and Just-in-Time Access Explained (5 min read): standing privilege versus just-in-time access, and where PAM sits relative to credential lifecycle management.
Suggested order: incident, then mechanism, then discipline, then access model.
The takeaway
If you take one thing from the Origin breach, take this: credential lifecycle is a process discipline. A credential on a vendor's platform gets revoked only when a process exists, someone owns it, and you can prove access died everywhere.
Where you start depends on your question, and the Resource Hub above maps each question to its article. Pick the one that matches and start there.
Frequently Asked Questions
Was the Origin Energy data breach a ransomware or malware attack?
No. Reporting points to an unrevoked credential on the Kraken customer-management platform, not malware or a novel exploit. A credential that stayed live after it should have died let someone reach customer data without breaking in. That is why Origin released no indicators of compromise, no CVE and no ATT&CK mapping: there was no vulnerability to patch, only a process to fix.
What is Kraken, the platform at the centre of the Origin breach?
Kraken is the customer-management platform involved in the Origin breach. It is a third-party system that Origin used to run customer accounts, and the reported access path was a credential tied to that platform. Because a vendor operated the system, that credential sat outside Origin's own offboarding checklist, which is the exact blind spot that let it survive.
How do I find out whether my details were in the Origin Energy breach?
Watch for direct contact from Origin Energy and check its dedicated incident update page, which is where affected-customer guidance is published. Do not wait for a generic email to confirm it; if your details were among the roughly 900,000 records accessed, expect specific notice. Treat any unsolicited message about the breach as a phishing risk and verify through Origin's own channels first.
What can someone actually do with my bank account number if it leaks?
A full bank account number alone is limited, but combined with your name and other personal details it becomes useful for fraud. That is why the roughly 60 exposed full bank account numbers matter more than their small count suggests. Watch your statements for unfamiliar transactions, and never confirm account details to someone who contacts you claiming to be from the bank or Origin.
Why did Origin Energy wait three weeks to disclose the breach?
Origin was first contacted on 2 July but went public on 22 July, a three-week gap. Disclosure timing involves investigation, legal advice and notification obligations, but the delay itself drew scrutiny and contributed to the fallout. For customers, the practical lesson is that a quiet period after an incident does not mean nothing is happening behind the scenes.
Is an unrevoked credential a vulnerability I can patch?
No. An unrevoked credential is a process failure, not a software flaw, so there is nothing to patch. You remove the risk by revoking the access, not by updating a system. That distinction is why the Origin case produced no CVE and no ATT&CK mapping: the fix is an offboarding control that actually reaches every platform, including third-party ones.
What is a non-human identity, and why does it matter for credential risk?
A non-human identity is a credential used by a system, service or application rather than a person, such as a service account or API key. These accumulate silently because no employee departure triggers their review, so they can sit unused for years while still granting access. In practice they are the orphaned accounts nobody owns, which makes them ideal for an attacker to borrow.
What is privilege creep, and how does it build up?
Privilege creep is the gradual accumulation of access rights a person collects as they change roles, pick up projects and cover for colleagues, without old permissions ever being removed. Over time an account holds far more than its current job needs. It matters because every extra permission widens the blast radius if that credential is later stolen or left unrevoked.
Is just-in-time access the same as least privilege?
No. Least privilege limits how much access an identity holds, while just-in-time access adds a duration dimension by granting elevated rights only for a bounded task and revoking them automatically. Both shrink blast radius, but only the time limit closes the window that an unrevoked credential exploits. Used together they address both how much and how long.
What is break-glass access in a just-in-time model?
Break-glass access is a governed emergency path that grants elevated privileges immediately when a normal just-in-time request would be too slow, such as during a major outage. The point is that it is still controlled: the access is logged, alerted on and reviewed afterwards. It gives you a way to respond to an emergency without restoring permanent standing privilege to everyone.
If we have limited headcount, where should we start with credential lifecycle management?
Start with offboarding, because that is the stage where the Origin-style failure happens and where auditors most often find gaps. You need to prove that access dies everywhere, including on vendor platforms, not just in your own directory. A single owner, a checklist that covers third parties and a periodic reconciliation of live accounts will catch more than any new tool.
How often should we audit accounts and access for orphaned credentials?
There is no universal interval, but the goal is to reconcile live accounts against current staff, contractors and vendors often enough that a departed user is caught in weeks, not years. Any account whose owner has left should be treated as a finding, not a tidy-up task. Pair the review with offboarding events so every departure triggers an immediate check.