Medtronic and Carnival, read as identity blast-radius failures

In the second half of April 2026, ShinyHunters listed two unrelated organizations on its leak site within forty-eight hours of each other. Medtronic, the medical-device giant, on April 16. Holland America's Mariner Society loyalty program, run by Carnival, on April 18. The first claim was 9M+ records of personal information plus internal corporate data. The second was 8.7M records — 7.5M unique email addresses — with names, dates of birth, genders, and membership status. Medtronic's own disclosure language is vague enough to drive a truck through ("an unauthorized party accessed certain internal systems"). Carnival attributes the whole incident to a single phished user account, which is a short sentence that has to do a lot of work to explain a 7.5M-row exfil.

This post is not a forensic reconstruction — neither company has published enough for that. It is a structural read of what the two disclosures actually imply, and where surfaces in Setu's product would have moved the outcome for a customer whose telemetry sat in either of those shapes.

The two disclosures, side by side

What is publicly known as of April 30, 2026:

Two non-vendors, two industries, one quiet weekend on the leak site.

The shape both disclosures imply

The Carnival framing is the more revealing one, because it commits to a specific claim — one phished account — that is in tension with the scale. A loyalty database with 7.5M unique members is not, in any normal architecture, something a single user-tier account holds standing read access to. If the public narrative is true, that one account had access far beyond what its job description should have implied, and the only thing standing between a routine credential phish and a 7.5M-row exfil was the attacker's willingness to run the query. That is a blast-radius problem, not a phishing problem. Phishing is the transport. The damage is set by what the credential could already reach.

Medtronic's disclosure does not commit to anything specific, but the shape of the claim — 9M+ records plus internal corporate data, with assurance that hospital device networks were unaffected — is consistent with the same pattern at one tier up. An attacker who got into corporate IT and was able to range across HR, finance, and customer datasets without crossing into the device-network segment had, again, a blast radius set by what the entry credential reached. In Medtronic's case the segmentation of the device networks is the part that worked. The segmentation of the corporate IT estate against itself is, on the public evidence, less load-bearing.

Both incidents are structurally about how far one foothold could see, not about the moment the foothold was created. That is the design question Setu's product is built around, and it is also why event-ordered SIEM detection consistently misses this class of campaign — a phish that leads to a single SaaS login is, on its own, an ordinary event. The shape only becomes a story once you ask what that one identity now reaches, and at what tempo it starts using the reach.

What a SIEM-only SOC sees in the Carnival shape

Walking the publicly stated chain through a conventional SIEM produces an alert stream like this:

Zero to one alerts. The campaign is invisible at the event tier because every individual event is the documented behavior of the system when the right credential is presented.

How Setu's surfaces map to the two shapes

Setu is a structural layer that sits over the identity, endpoint, and control-plane telemetry a customer already has, and produces surfaces that reason about shape rather than events. Five of those surfaces are directly relevant to the Medtronic / Carnival shape — four fire at the right moment, one is an honest gap.

Surface 1 — Hygiene scanner, before the breach

The hygiene scanner runs five rules over the identity surface a customer has already exported from their IdP/AD. Two of the five matter here:

• Blast-radius / role mismatch. Accounts whose reachable-resource score is incompatible with the job description. The "single phished user account" in the Carnival framing is exactly the rule's target — an identity whose 99th-percentile reach exceeds the 90th-percentile reach of identities with the same role, with no documented business reason for the gap. The scanner ranks these accounts in a weekly hygiene report. The reasoning, surfaced inline, is the centrality and betweenness of the account in the entity graph: the marketing-tier account that can read the loyalty database sits on a high-betweenness path between the phishing-prone perimeter and a crown-jewel data store, and the graph says so.
• Standing access without recent use. Accounts that hold read access to high-sensitivity data they have not actually used in N days. Different rule, same kind of finding: latent access surface that costs nothing to revoke and pays a large negative dividend the day it gets phished.

Neither rule prevents the phish. Both reduce the standing inventory of identities for which a phish becomes a 7.5M-row incident. This is pre-incident hygiene — and on the public facts, it is the part that was missing in the Carnival case.

For Medtronic, the same surface applies one tier up, to corporate-IT segmentation. The questions it answers — which identities span the most boundary-crossing edges, which standing grants haven't been exercised in the last quarter, which third-party integrations carry scopes that exceed their function — are the questions the post-incident review is presumably answering now, except now under a deadline.

Surface 2 — Entity graph, during the pivot

The entity graph engine does personalized PageRank with event-biased restart. When a credential is used, the restart bias weights toward that event, and the subgraph that lights up is the one the attacker can actually reach right now from that foothold.

In the Carnival shape, the moment the phished credential is used to log in to the loyalty admin tool, two structural signals show up:

• Centrality delta. The account has a baseline PPR score it has held for months. The same account, restarted from this hour's event, lights up nodes — the loyalty DB, the export tool, customer-record objects — that its baseline never reached. The delta is in the top tail of the daily distribution.
• Bridge violation. Betweenness centrality on the account spikes as it begins traversing edges between clusters that historically were not connected through it. The marketing-analyst-shaped account is suddenly behaving as a bridge between corporate auth and customer data.

Neither signal is a rule. Both fall out of the graph being there.

For the Medtronic shape, the same surface answers the question "what does this internal-systems foothold currently see?" If the entity graph spans the corporate-IT estate, the moment the attacker pivots, the subgraph that lights up has a measurable size — and the size of that subgraph is, in distribution terms, the blast radius the disclosure language is currently being vague about.

Surface 3 — Velocity scorer, during exfil

The per-node activity scorer measures each identity's tempo against its own 30-day baseline. A phished marketing-tier account suddenly executing the largest queries it has ever run, against tables it has never previously touched, at a fan-out that does not match its embedding, is in the top tail of the distribution by every metric the scorer computes.

This is the cleanest signal in either chain. It is also the one that depends most on the customer having wired their data-platform audit log into Setu. Without that telemetry, the surface does not fire. With it, it fires before the export completes — not after the leak-site listing.

Surface 4 — Setu Companion, on the Medtronic-shaped estate

Setu Companion is an on-prem agent — Wazuh + ETW + syslog/SNMP relay — designed for environments where SaaS-only EDR coverage is incomplete or unavailable. It is the reason Setu has been deployable in air-gapped contexts (the Laurus pattern), and it is the surface that matters for Medtronic-shaped estates specifically. The corporate-IT estate adjacent to a regulated network is exactly the place where SaaS-native XDR vendors quietly admit their coverage thins out, and where an attacker who has reached "internal systems" gets to range without per-host telemetry that would make their movement visible.

The Companion's edges feed into the same entity graph as the SaaS-side telemetry. The point is not endpoint detection in isolation. The point is that a credential pivot from a corporate workstation toward a system that talks to the regulated network shows up as a single cross-domain edge in one graph, not as two unrelated logs in two unrelated tools.

Surface 5 — Attack Dispatches feed, during and after

The Dispatches feed runs bipartite connected-component clustering and Jaccard identity over the anomalous-subgraph output from Surfaces 2 and 3. Its job is to collapse "several nodes lit up, go look" into one narrative object with a title, severity, and a list of member entities.

For the Carnival shape, the cluster is the phishing event, the credential, the admin-tool session, the loyalty DB query path, and the rows exfiltrated. The template narrator produces a headline along the lines of: "Marketing-tier identity inherited from a phishing event; reading 7.5M rows from a customer-loyalty store inside a 4-hour window; baseline access pattern was 200 rows/week against unrelated objects." Rank-score decay keeps it at the top of the SOC queue while it is still in progress.

A human analyst picks the dispatch off the top of the feed and reads one paragraph. They do not need to correlate across the IdP audit, the SaaS admin audit, and the data-platform query log themselves. The correlation is what the feed exists to do.

What this post is and isn't claiming

A few honest qualifications:

• Neither Medtronic nor Carnival is a Setu customer. The above is what Setu's surfaces would produce if either company's telemetry had been ingested the way Setu customers ingest their own. We are reading the public disclosures and naming where the structural prevention surface would have lived, not claiming we would have stopped either incident.
• The graph surfaces depend on the graph being built. The centrality, betweenness, and velocity-score signals assume the customer has wired their IdP audit, their data-platform audit, and (for Medtronic-shaped estates) their on-prem endpoint audit into the ingest. A customer with only one of three in place gets a partial picture.
• Setu does not stop the initial phish. That is the email and IdP layer's job, and pretending otherwise is the kind of overclaim that loses CISO trust by slide three. The narrower, honest pitch is: given an attacker gets one credential, what is the blast radius (Surface 1's pre-incident answer), and how fast does the SOC see the campaign coalesce as one story (Surfaces 2, 3, and 5's during-incident answer).
• The "single phished account" claim may be incomplete. It usually is. If the actual chain in Carnival's case turns out to involve a service principal, an OAuth grant to a marketing-automation vendor, or a third-party CRM integration, the structural surfaces shift one tier — the same hygiene rule fires on the integration's standing scope rather than on the user's role-mismatch — but the framing does not change.
• Blast-radius work is unglamorous. The day-one return on Surface 1 is "12 accounts and 4 integrations to fix this week." It is not exciting. It is the work that determines whether next quarter's phishing event becomes a 200-row incident or a 7.5M-row one.

The broader shape

The pattern across late-April 2026's disclosures is the same one that has been running through the last two years of major incidents: Okta-via-support-vendor in 2023, Snowflake customer-credential incidents in 2024, Salesloft / Drift in August 2025, Vercel / Context.ai in April 2026, and now Medtronic and Carnival in the same week. The mechanism varies — phishing, infostealer, OAuth abuse, credential reuse — but the structural failure is the same. One identity, or one trusted integration, ended up holding far more reach than its job needed; the moment it was compromised, the blast radius was already set; and event-tier detection had nothing to say about the access surface that made the campaign possible.

SIEMs detect events. They do a reasonable job there, and Setu does not replace that. What they cannot do is reason about the shape of an identity's reach before it is exercised. That is the surface Setu is built around. The Medtronic and Carnival disclosures are the current cleanest examples of why that surface — in production, on day one — is the part of the stack that determines what the post-incident headline gets to say.

---

Sources and further reading

• Infosecurity Magazine: Medtronic confirms data security incident as ShinyHunters lists 9M records
• Have I Been Pwned: Holland America / Mariner Society dataset
• Prior coverage: The Vercel April 2026 breach, read as a campaign — same structural pattern at the OAuth tier

---

Events are facts. Relationships are context. Campaigns are the dispatch your attacker is writing. You need all three to read it.