UK GDPR Article 32 and the Secret in the Browser: What the Manchester Airports Group Breach Demands of Every Controller in 2026

On 27 August 2026, Manchester Airports Group confirmed that an unauthorised third party had accessed customer data across all three of the airports it operates — Manchester, London Stansted and East Midlands. MAG is the UK’s largest airport operator by passenger volume, and the figure attached to the incident, around 8.7 million customers, makes it the largest known customer data breach involving a British airport group.

The company’s account is narrow and precise. The data relates to car park bookings, lounge bookings, Fast Track bookings and in-airport Wi-Fi sign-ups: email addresses, phone numbers, vehicle registration numbers and postcodes, with email addresses the majority, largely from free Wi-Fi registration. MAG says no bank or payment card details were held, operational airport systems were not involved, and flights were unaffected. It detected the incident on 25 August 2026, restricted access, engaged specialist advisers, and notified the National Cyber Security Centre and the Information Commissioner’s Office. A ransom was demanded; MAG is understood to have refused to pay.

The extortion group FulcrumSec tells a larger story. It claims roughly 86 GB of exfiltrated data, and it claims something more specific and more damaging: that it obtained access using airport-specific Iterable API credentials exposed in client-side JavaScript.

That claim is why this incident belongs in a compliance publication rather than a news feed. Client-side JavaScript runs inside the visitor’s own browser. A credential placed there is not protected by obscurity and is not “internal”: anyone who opens developer tools, reads the page source, or runs one of the scanners that continuously crawl the public web for exactly this pattern can read it. If the claim is confirmed, MAG faces the hardest category of UK GDPR Article 32 case there is — a failure where the preventive control is cheap, standard, and documented in every mainstream secure-development guide of the last decade.

What Is Confirmed, What Is Claimed, and Why the Gap Is Itself a Compliance Issue

The two accounts do not match, and attribution matters.

Claimed by FulcrumSec, not confirmed by MAG: approximately 86 GB in total; the Iterable credential exposure as the access mechanism; a roughly 21.5 GB Manchester customer export combining customer identifiers with historical booking activity and marketing classifications; and nearly 200,000 records relating to upcoming travel during the remainder of 2026.

Partially corroborated: BleepingComputer, reviewing samples the group provided, reported material considerably more detailed than MAG’s disclosure implied — purchase references, booking and arrival times, terminal, amounts paid, total spending, IP addresses, device information and approximate location — and validated at least one record against a traveller’s known purchase history. MAG has declined to address either the dataset size or the credential claim.

Attacker claims are marketing, extortion groups inflate, and declining to confirm a leak-site figure is entirely reasonable. But a compliance question sits underneath that does not depend on believing FulcrumSec: notification must be assessed against the data actually taken, not the data the controller finds convenient to describe. Article 34(2) requires the communication to affected individuals to describe the likely consequences in clear and plain language, and Article 33(3) requires the ICO notification to describe the categories and approximate number of data subjects and records concerned. A disclosure listing “email addresses, phone numbers, vehicle registrations and postcodes” and one listing “consolidated behavioural profiles including historical spend, device fingerprints, IP addresses, approximate location and forward-dated travel itineraries” support materially different risk assessments by the recipient. If the second is closer to the truth, the first under-informed people about the risk they were being asked to manage.

Article 33(4) is the mechanism for this: where information is not available at the time, it may be provided in phases without undue further delay. The failure mode is not saying too little on day two; it is never revising day two’s account once the forensics catch up.

Article 32: Why “Appropriate” Has No Room Left in It Here

Article 32(1) of the UK GDPR requires technical and organisational measures appropriate to the risk, “taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons.”

The word doing the work is appropriate. It is a proportionality standard, and normally where controllers have room to argue: the measure was expensive; the risk speculative; the state of the art unsettled. None of those arguments are available for a secret in a front-end bundle. Take each limb in turn.

State of the art. Automated detection of credentials in source code and in built artefacts is not emerging technology; it is a commodity. Open-source scanners — gitleaks, trufflehog, detect-secrets — are free, and GitHub, GitLab and every major CI platform ship secret scanning as a built-in feature. Iterable, like most SaaS vendors, distinguishes between server-side API keys and restricted client-side keys precisely because the vendor anticipated this failure and built a safer option. The state of the art here is not merely settled; it is the default.

Costs of implementation. A pre-commit hook and a CI job, measured in engineer-hours, once, against 8.7 million data subjects.

Nature, scope and risk. Large-scale processing of consumer personal data by a national infrastructure operator, through public-facing web properties, with a marketing platform holding consolidated customer profiles — and a risk profile, discussed below, worse than it first appears.

When every input to the test points the same way, “appropriate” stops being a spectrum and becomes a floor.

There is direct sectoral precedent, and it is unhelpful for MAG. In October 2020 the ICO fined British Airways £20 million under Articles 5(1)(f) and 32 for the 2018 Magecart compromise — the finding being not that BA was attacked, but that it lacked measures that could have detected or prevented the compromise of a third-party script in its payment flow. A UK aviation operator penalised under Article 32 for insufficient control over what runs in, and what is exposed by, the browser is not hypothetical. It has happened once already.

Note the doctrinal point underneath. Article 5(1)(f) makes integrity and confidentiality a principle, and Article 5(2) accountability requires the controller to be able to demonstrate compliance with it. Under Article 83(5), infringements of Article 5 attract the higher penalty tier — up to £17.5 million or 4% of total worldwide annual turnover — where Article 32 alone sits in the lower tier at half that. The ICO has consistently pleaded the two together in security cases, so assume the higher tier is in play.

Accountability bites specifically here: a policy saying “do not put secrets in client-side code” is not enough. The controller must show the mechanism that enforced it — the scan, the gate, the review step, the exception log. A policy without an enforcement artefact is, for Article 5(2) purposes, an assertion.

The Aggravating Factor Nobody Should Skip: Forward-Dated Travel

Marketing databases leak constantly, and the standard risk assessment writes itself: phishing, spam, credential-stuffing. Familiar harms. The claim of nearly 200,000 records relating to upcoming travel during the remainder of 2026 is a different risk class, and should be assessed as one.

A record tying a named individual to a vehicle registration, a home postcode, and a future airport arrival time is not marketing data. It is a statement that a specific, locatable home will probably be unoccupied on known dates, and that a named person will be somewhere at a known time. That supports residential burglary targeting; vehicle targeting, since the registration and the car park booking identify a known car in a known place for a known window; stalking and domestic-abuse risk, where an abuser learning a former partner’s travel plans is a physical-safety event; and highly credible pretexting, because a message correctly citing the reader’s flight date, terminal and booking reference defeats the heuristics people actually use.

Article 34(1) requires communication to the data subject without undue delay where the breach is “likely to result in a high risk to the rights and freedoms of natural persons”. Those rights are not limited to informational privacy: physical security and the right to private and family life sit inside the assessment, and forward-dated travel data pushes towards the high-risk threshold in a way a list of email addresses does not. Article 34(2) then requires a description of the likely consequences: if that section says “be alert to phishing” and not “consider that your travel dates may be known to a third party”, it is incomplete against the risk that exists.

Article 5(1)(c) data minimisation and 5(1)(e) storage limitation then invite the question any regulator will ask: why was a marketing engagement platform holding forward-dated itinerary detail at all? Personalisation rarely requires that field, and every additional element synchronised into a SaaS tool expands the blast radius of its compromise.

The instruction generalises: run your breach severity model against the worst field in the dataset, not the average one.

Article 28 and the Iterable Relationship: The Credential Is the Controller’s Problem

Iterable is a third-party marketing and customer-engagement platform, and the instinct after an incident like this is to reach for vendor liability. That instinct is wrong here.

MAG determines the purposes and means of processing its customers’ data: MAG is the controller. Iterable processes that data on MAG’s documented instructions: Iterable is the processor. Article 28(3) requires a written contract binding the processor to implement Article 32 measures, assist the controller in complying with Articles 32 to 36, and notify the controller without undue delay of a personal data breach.

But the alleged failure is not a failure of Iterable’s platform security. On the claimed facts the platform did what it was asked: it accepted an authenticated API call presenting a valid credential. The credential was published by the controller, in the controller’s own web property, into the browsers of the controller’s own customers.

The allocation applies to every SaaS integration. The processor’s duty is to secure its platform, offer credentials that can be scoped and rotated, log API activity, and support oversight. The controller’s duty under Article 32 is the handling of the credentials that address that platform — where they are stored, how they are scoped and rotated, who can issue them, and above all whether any of them ever reach client-side code.

A data processing agreement does not transfer the second duty. No clause makes a vendor responsible for the fact that you published its API key. This is the structural lesson of the Lidl third-party breach and its processor-risk analysis: the contract governs the processor’s conduct, not the controller’s own integration hygiene.

Two further points belong in the post-incident review. Article 28(3)(h) entitles the controller to audit the processor, including what API activity logs exist and whether anomalous export volume triggers an alert. And the Article 30(1) record of processing activities should already identify every processor and the data flowing to each: if the post-incident scoping exercise is where you discover what fields were synchronised into your marketing platform, that record was decorative.

The NIS Question: Be Careful, Because the Answer Is Probably “No”

Aviation attracts a second regulatory layer, and this is where commentary tends to become imprecise. Under the Network and Information Systems Regulations 2018 (SI 2018/506), the air transport subsector includes the owner or manager of an aerodrome, and Schedule 2 sets the UK threshold at annual terminal passenger numbers greater than 10 million. Manchester and London Stansted both exceed it, so MAG operates airports falling within designation as operators of essential services (OES), with the Civil Aviation Authority as competent authority. The CAA’s oversight approach is set out in CAP 1753, supported by the ASSURE accredited third-party cyber audit scheme developed with the Department for Transport and NCSC, and by CAP 1849 scoping guidance for critical systems.

Here is the distinction that must not be blurred. NIS duties attach to the network and information systems on which the provision of the essential service relies — airfield operations, baggage and passenger processing, security screening, fuel and stand management: the systems without which aircraft do not move safely.

A marketing platform, a car park booking portal, a Fast Track e-commerce flow and a terminal Wi-Fi captive portal are, on the face of it, ordinary commercial systems: they generate revenue and process a great deal of personal data, but their failure does not stop the essential service. MAG’s statement that operational systems were not involved and flights were unaffected is precisely what keeps this incident outside NIS incident-reporting scope under Regulation 11, whose trigger is significant impact on the continuity of the essential service.

Three qualifications keep this from being a clean escape.

Scoping is not self-certifying. CAP 1849 exists because the boundary between critical and commercial systems is contested, and it is drawn by reference to actual architecture, not org charts. If the compromised estate shared identity infrastructure, network segments, administrative credentials or a cloud tenancy with in-scope systems, the boundary was thinner than the disclosure implies. The CAA’s interest is less “was the marketing database in scope” than “demonstrate that it was properly segregated from what is” — an evidence question that lands immediately.

Terminal Wi-Fi is a genuinely awkward asset. It sits inside the aerodrome, is used airside, and in many airports touches operational network infrastructure. Whether a captive portal is a commercial marketing system or an appendage of airport network infrastructure is exactly what CAP 1849 is meant to resolve — and exactly the question organisations discover they never resolved.

The perimeter is about to move. The Cyber Security and Resilience (Network and Information Systems) Bill cleared the Commons and entered Lords Committee on 1 September 2026, with Royal Assent expected late in 2026. It amends the 2018 Regulations, brings managed service providers, data centres and designated critical suppliers into statutory scope, tightens reporting toward a 24-hour initial notification, and raises penalties to £17 million or 4% of global turnover. The trajectory since the Bill’s original announcement has been consistently towards more entities, shorter clocks and larger fines.

“That system is not in scope” is a comfort supplied by a 2018 statute written before consumer-facing digital estates were this large or this interconnected. Build the segregation evidence now.

The ICO Angle: Enforcement Posture and What Actually Drives the Outcome

MAG appears to have handled the notification mechanics correctly. Detection on 25 August, ICO and NCSC notified, public disclosure on 27 August — comfortably inside the Article 33(1) 72-hour window that runs from the moment the controller becomes aware of the breach. Refusing to pay is also the position UK policy favours, consistent with the direction of travel examined in our coverage of the proposed UK ransomware payment restrictions.

Correct notification does not resolve the Article 32 question. The ICO’s recent security cases turn overwhelmingly on the control environment before the incident, not the response after it:

British Airways, £20m (2020) — Articles 5(1)(f) and 32; third-party script compromise; insufficient controls around the client-side payment flow.
South Staffordshire Water, £963,900 (May 2026) — a 2022 Cl0p compromise, penalised nearly four years later on the measures in place at the time.
Capita, £14m (December 2025) — a 2023 breach, two years to enforcement, again on pre-incident controls.
LastPass, £1.2m (December 2025) — a penalty bearing little relation to downstream harm and everything to the inadequacy of specific measures.

Enforcement is slow, and that is not reassurance: a decision on MAG is realistically two to four years away, and everything done in the interim — remediation, notification quality, cooperation — is evidence in that future file.

Article 83(2) factors are where the number moves. Cooperation, remediation speed and harm mitigation pull down; the categories of data, the number of data subjects, the degree of responsibility having regard to the measures implemented, and — critically — whether the infringement was negligent rather than merely unlucky, pull up. A credential in a public bundle is on its face a negligence finding rather than a sophisticated-attacker finding, and controllers should expect the ICO to characterise it that way.

Regulatory exposure is not the only exposure. Article 82 compensation claims follow large consumer breaches, and the forward-travel records give claimant firms a physical-risk narrative that ordinary marketing-data claims lack.

The Control Set: Preventing a Secret From Reaching a Browser

The legal analysis above is only useful if it changes what gets built.

Why this happens, structurally

It is tempting to treat a key in a bundle as carelessness. It is more often architecture. Modern front-end build tools deliberately expose a subset of environment variables to the browser, signalled by prefix convention: in Next.js any variable prefixed NEXT_PUBLIC_ is inlined into the client bundle at build time; in Vite the prefix is VITE_; Create React App used REACT_APP_. The convention is documented and sensible, and it is also a footgun with a specific failure mode: a developer who cannot read a value in the browser fixes the problem by adding the prefix. The variable becomes visible, the feature works, the pull request passes review because the diff is one word long, and a server-side secret is now compiled into a public asset served from a CDN.

The second driver is calling vendor APIs directly from the browser: faster to ship, and many vendors document a browser SDK — but a browser cannot keep a secret. The third is credential scope: a key issued to send a single event is often also able to list, read and export.

Controls

Scan for secrets in three places, not one. Scan commits, via pre-commit hooks and push protection; CI pipelines, as a blocking gate on merge; and critically the built artefacts — the compiled bundles, source maps and static assets actually deployed. A secret injected at build time from an environment variable does not exist in the repository at all, so repository scanning would never find it. Its absence is why organisations with mature secret scanning still ship keys to browsers. Our earlier treatment of secrets sprawl as a compliance failure sets out the wider governance picture.

Monitor the deployed site from the outside. Periodically fetch your own production JavaScript as an anonymous visitor and scan it for credential patterns. This is the attacker’s view, and it catches what internal tooling misses — tag manager injections, vendor scripts, marketing tags added outside the release process. Extend it to an inventory of every script executing on your pages; CSP allowlisting plus Subresource Integrity turns that inventory into enforcement.

Use a backend-for-frontend proxy. The architectural fix: the browser calls your own endpoint, and your server holds the credential and calls the vendor. You get authentication on your terms, rate limiting, per-user scoping, audit logging, and a single place to rotate a key. One small service removes the whole class of vulnerability.

Scope every credential to the minimum, prefer short-lived ones, and rotate automatically. Where a vendor offers restricted client-side keys, use them — and confirm what they can actually do rather than trusting the label. Never use an admin key in an integration. Rotation must be routine and automated: if it requires a coordinated change across six services and a deployment freeze, you will not do it when it matters.

Monitor the vendor side for anomalous export volume. This is where detection actually lives for this attack class. A credential that normally writes events and suddenly performs bulk list exports is a detectable signal — but only if someone ingests the vendor’s API logs and alerts on volume, endpoint and geography. Ask every SaaS processor what API activity logging it provides, and write it into the Article 28 contract.

Checklist

Conclusion

Every element of the MAG incident that a regulator will care about was decided before 25 August 2026. If the FulcrumSec account holds, the failure is not a sophisticated intrusion but a credential that a build pipeline compiled into a public asset, served to millions of browsers, readable by anyone who looked. Article 32’s proportionality test offers no shelter when the missing control is a free scanner in a CI pipeline — and the ICO has already fined a UK aviation operator £20 million over client-side code once.

Two things generalise. The contract does not follow the data: a processor agreement with a SaaS vendor is essential, and does nothing about how the controller handles the key that addresses that vendor. And breach severity is set by the worst field, not the modal one: a dataset containing nearly 200,000 forward-dated travel itineraries tied to home postcodes and vehicle registrations is not marketing data, whatever it is called.

Fetch your own production JavaScript bundle, as an anonymous visitor, and scan it. It is the cheapest Article 32 evidence you will ever generate — and if it comes back clean, the record of having looked is worth having.

This article is provided for informational purposes only and does not constitute legal advice.