The Authorization Was Legitimate. Nobody Watched What Happened Next.

A session control gap — not a broken identity control — is why approximately 5.67 million Qantas customer records were compromised. No password was stolen. No multi-factor prompt was defeated, because the attacker never logged in at all. The Office of the Australian Information Commissioner concluded its preliminary inquiries in July 2026 without commencing a formal investigation or taking regulatory action — a decision the OAIC was explicit is not a concluded finding, and doesn’t foreclose acting later. The finding underneath that conclusion is the architecturally interesting part: the agent who set the breach in motion had a legitimate, standing right to be exactly where they were in the CRM. What failed wasn’t the agent’s identity or their role. It was a default platform setting that let that legitimate access authorize something new — a connected application — with nothing checking what that new connection would go on to do.

The Architectural Surprise

Most breach retrospectives look for the moment a control failed — the password that leaked, the MFA prompt that got bypassed, the firewall rule that never shipped. Qantas doesn’t give you a clean one. A caller impersonating “Qantas IT help” reached a third-party contact-center agent on a Saturday, walked them through what looked like routine ticket-closure steps, and directed them to Salesforce’s own connected-app setup page to enter an eight-digit connection code. That code registered the attacker’s tool — a modified version of Salesforce’s own Data Loader utility — as a trusted connected app on the agent’s account. The agent’s authenticated session authorized the connection. Salesforce saw a legitimate, logged-in employee approving an app, and issued an OAuth token carrying that employee’s own standing permissions.

Here’s the distinction worth holding precisely, because it’s easy to collapse: the agent already had a legitimate, standing right to view customer contact profiles across the CRM — that was the job. What the agent didn’t have was a legitimate reason to authorize a new third-party connection, and a default Salesforce configuration let any end user do exactly that, with no additional approval gate. Salesforce has since changed that default industry-wide. The identity was never in question. The intent behind one specific action was — and the platform’s authorization flow had no step built to ask about it.

What Actually Happened

The chain is worth holding as a single sequence, because almost every individual link is defensible on its own — that’s what makes the eventual session control gap hard to see coming: a vishing call, framed as an internal IT-support contact, reaches a contact-center agent on a Saturday. The pretext is a routine ticket closure. The agent is walked through Salesforce’s own connected-app flow and enters a connection code, registering the attacker’s tool as a trusted app operating under the agent’s existing authority — no new privileges provisioned, no elevation, just a new connection exercising authority the agent already held. The tool runs bulk queries through the Salesforce API, extracting roughly 5.67 million records — about 4 million with names, emails, and Frequent Flyer detail; a further 1.7 million with additional personal information.

Two system alerts did fire during the attack — an unusual volume of failed login attempts, incidental noise generated somewhere nearby, not the access vector itself. They sat unread over the weekend and were escalated only when a staff member reviewed them Monday morning; Qantas froze the account and began containment the same day. The detection wasn’t absent, and it wasn’t slow because nobody was watching. It was watching the wrong signal. Real-time exfiltration monitoring — the kind that flags bulk record retrieval through an API and can auto-terminate the session — is designed to detect this class of behavior, and it wasn’t the control that happened to be in the path.

The Question Nobody Was Asking

Three separate questions get collapsed into one in most access-control thinking, and separating them is what makes an incident like this legible instead of paradoxical:

Most identity and access programs are built almost entirely around question one. Question two arrives, when it arrives, as a compliance afterthought — a self-attestation, a quarterly access review, rarely something checked against what actually happened afterward. Question three is rarer still, not because it’s unrecognized as valuable but because the tooling that answers it — API-level exfiltration monitoring, behavioral baselining, session-scoped rate limiting — sits in a different product category than identity and access management, and gets treated as optional hardening rather than the load-bearing control it actually is. That gap between the two categories is the session control gap in practice, not just in name.

This isn’t the same failure described in Identity Directory Egress. That pattern starts with a standing permission whose read authority was never bounded — a role that could always pull a full directory export, quietly, because nobody scoped what “read access” should mean at volume. Qantas starts with a new connected-app authorization, fraudulently induced, operating under authority the agent already held. One is entitlement scope; the other is the session control gap this piece is about — post-authorization control over a fraudulently induced connection. The shared surface — bulk activity that looks exactly like normal platform use — is what makes both worth naming, and the difference is what keeps either from collapsing into the other’s fix.

The same three-question lifecycle is worth a related citation: Third-Party Cloud Access examines what happens when a vendor’s security perimeter fails but the authority it was delegated into your infrastructure was never actually revoked — a different trigger (a broken relationship, not a fraudulent grant) inside the same family of authority outliving the thing that should be watching it.

Why the Session Control Gap Is Structural, Not a Vendor’s Mistake

It would be comfortable to read Qantas as a training failure. It isn’t, quite — and the OAIC said as much directly: most social-engineering training addresses credential theft, not the far less common tactic of inducing an employee to authorize access through a legitimate system interaction, and the report concluded standard training would likely have failed here too. Qantas had supplier audits, ISO 27001 compliance from its vendor, role-based access controls, and cybersecurity training in place — individually reasonable measures, which is exactly why the OAIC closed its inquiries without further action. None of them addressed the specific boundary this incident crossed.

That’s the session control gap worth naming as an architecture problem: controls can each be individually reasonable while the system still lacks a strong control boundary between legitimate authorization and anomalous use of that authorization. A connected app that inherits a user’s permissions creates a second control question that role-based access alone doesn’t answer — should the app’s effective authority be identical to the human user’s, especially once its behavior can operate at API scale, in bulk, in a way no human using that same role ever would? The incident points toward several answers that don’t require re-architecting identity from scratch: restricting connected-app authorization to administrators rather than any end user — the fix the CRM provider has since made the default industry-wide — real-time exfiltration monitoring capable of flagging bulk API extraction and auto-terminating the session, and a callback-verification requirement for unsolicited IT contact that would have directly countered the pretext that started the chain.

None of that is a checklist item bolted onto identity and access management after the fact. It’s a recognition that authorization is not a single event verified once at the door. It’s a standing relationship between an identity and a system, and like any standing relationship, it can be established through entirely legitimate means and still end up somewhere nobody intended.

Architect’s Verdict

A successful authorization event is not proof that everything that follows deserves trust. Qantas’s controls asked the questions they were built to ask — is this identity permitted to be here, does this login pattern look normal — and answered both honestly. Roughly 5.67 million records left the building anyway, because neither question was ever the one that would have caught it.

The real problem this incident exposes isn’t a vendor’s contact center or a single social-engineering script that will look dated within a year. It’s a category error sitting underneath most identity architecture: authorization is treated as though it settles the whole matter, when it only ever settles the first part of it. Every environment that grants standing access to a connected app, a service account, or a delegated integration is exposed to the same class of session control gap Qantas exposed — not because nobody built monitoring, but because nobody defined watching behavior as authorization’s job in the first place.

Authorization answers whether access may begin. It does not answer whether everything that follows deserves to continue.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →