Guest Wi-Fi is a database of people (and it is not in your inventory)

On 27 August, Manchester Airports Group confirmed that an unauthorised third party had taken customer data from Manchester, Stansted and East Midlands airports. Reporting puts the figure at around 8.7 million people. The fields: email address, phone number, vehicle registration and postcode. The source: car park, lounge and Fast Track bookings, plus in-airport Wi-Fi sign-ups. The company itself stresses that there was no operational disruption, that the airports kept running and that at no point was aviation security compromised. Everything worked. And it was still the worst day of the year for that company.

What was taken did not live in a critical system. It lived in the form people fill in standing up, suitcase propped against one leg, to get ten minutes of Wi-Fi. That is the part of this incident that does concern you, whether you run an airport or a thirty-person office with a waiting area: the system holding the most people is almost never the one at the top of your criticality list. And it is not there because the list is ordered by what happens if the system goes down, not by how many people are inside it.

What was taken, and what was not there

Let us start with the honest part: the figure is not in the statement. MAG says it has contacted affected customers directly without publishing any number; the 8.7 million comes from what a spokesperson told the press, and some local outlets have gone as far as 8.9, citing private company statements. We will take the lower figure and keep the caveat out in the open, because what matters here is the order of magnitude, and the order of magnitude is clear: millions of people who once tapped a screen to park or to get online.

Nor is it known how they got in. MAG refers to an "unauthorised third party", says it contained the risk immediately and that it temporarily suspended the Manage My Booking portal as a precaution. It has told UK media two things: that there was a ransom demand and that it refused to pay, and that it knows who is behind it and has passed that to the authorities. But there is no published vector, no group has publicly claimed the attack and nobody has shown the door they came through. Anyone telling you the how in detail today is making it up.

The interesting part is the sentence about payments. The statement does not stop at "the intruder did not access customer payment details", which is what everybody says. It also says, literally, that neither the company nor the affected system held customers' bank or payment details. Read that twice: an operator billing millions of parking stays a year has no card details stored. The company has not explained why, and we do not know; our reading — and we flag it as a reading — is that behind a sentence like that there is an architectural decision taken years earlier: delegate the payment and do not keep a copy. On the day of the incident, that decision was worth more than any security product in the catalogue.

The number plate is the field to watch

Of the four fields, three are the usual suspects. A leaked email and phone number feed spam and generic phishing, and most people reading this have been in twenty different dumps for years. A postcode on its own adds little. The number plate, though, is a different animal, for two reasons worth separating.

The first is credibility. An email saying "there is an outstanding charge from your car park stay" that gets your number plate right looks nothing like the ones that arrive every day. That is the quality jump fraud makes when somebody joins four fields that were worthless separately. Whether that happens here we do not know: it is our reading of what can be built with that combination.

The second is the one nobody says out loud: you cannot rotate a number plate like a password. Leak a password and you rotate it this afternoon. Leak an email and you live with it and add a filter. A number plate stays with you until you sell the car, and that is years. The same goes for a date of birth, a national ID number or the phone number you have had forever. Some data expires and some does not, and the kind that does not is the expensive kind: you pay for it once and keep paying for a decade. Worth keeping the two apart in your head when you decide which fields your form asks for.

Nothing went down. That is why it happened.

We have spent years repeating that failure is inevitable and an outage is a design decision: a broken part does not have to stop your business. This case forces you to turn the sentence around. There was no outage here in the classic sense: aviation security was not compromised and operations continued. If you measure your risk in minutes of downtime — which is how almost every risk inventory we come across measures it — this incident scores a clean zero. And it is still the one that will be in the press for months.

Here is the idea we take away, and it is an uncomfortable one: rank your systems by operational criticality, then rank them by how many people are inside, and the two lists come out almost inverted. The ERP, the phone system and the hypervisor sit at the top of the first one and typically hold data on a few hundred employees and active customers. The captive portal, the website contact form and the mailing tool sit right at the bottom — if they go down, nothing happens, people are annoyed for a while — and they are the ones holding the longest table in the building, with years of people who passed through once.

And because they are at the bottom of the list, they get bottom-of-the-list treatment — we are describing what we see in general, since nothing has been published about the vector in MAG's case: patched last, no clear owner, access wider than it should be, and quite often not even on the network you think they are. It is the same film we described with directories holding more records than employees: the system does not fail, it simply accumulates, and nobody looks at what it has accumulated until somebody else looks first.

Your front desk has the same thing, at another scale

Almost every company we work with has a guest SSID. Many have a captive portal that asks for an email before letting you browse, because it came in the vendor's setup wizard and looked like the proper thing to do. Almost none can answer these four questions at once: where does that email end up, who administers the place it ends up in, how many rows are in there, and since when.

The third answer usually surprises people. A captive portal installed four years ago in a company with daily visitors has piled up thousands of email addresses nobody has ever used for anything — because "we ask for it just in case, for marketing" almost never turns into an actual campaign. And the second answer surprises them more: on plenty of mid-range kit, the captive portal and its database are not in your office, they are in the access point vendor's cloud. That is processing carried out by a third party, with its own contract and its own location, and it almost never appears in the company's record of processing activities.

And there is a second risk running the other way, which we covered separately: it is not only that guest Wi-Fi stores data about whoever connects — somebody else's guest network can do things to whoever connects to it. Two sides of the same cable. Today's is the side of whoever offers it.

Six questions and one boring afternoon

You do not need a project. You need a list and somebody to write it. These are the six questions we start with when we walk into a new place:

• Where do you collect data about somebody who is not your employee? Captive portal, website form, bookings, the visitor sheet at reception, the tablet in the canteen, last year's trade show raffle. Write them all down, including the embarrassing ones.
• Who owns each one and where does the data end up? If the answer is "in the vendor's cloud", that is a supplier: contract, location, and what happens the day you leave that vendor.
• When does it expire? If nobody has ever deleted anything, the table goes back to day one. A scheduled deletion at twelve months breaks absolutely nothing and removes years of potential headline. The GDPR does not hand you a specific period: it requires you to justify the one you pick, so pick it before somebody asks.
• Do you actually need that field? Ask it field by field, out loud. To give a visitor courtesy Wi-Fi, in many places accepting terms or using an expiring code is enough. The email is asked for "just in case", and that "just in case" is what ends up in the press release.
• Which network is it on? The guest network should not see the LAN, the printer, the NAS or the other guest. Client isolation, its own VLAN, its own bandwidth cap. This is an afternoon of configuration, not a purchase.
• Could you say how many people are inside? The 72-hour clock in Article 33 of the GDPR does not get stuck on the legal side, it gets stuck here. The question that sinks a notification is not "do we have to notify?", it is "exactly how many people are we talking about and which of their fields were in there?". If you cannot answer that calmly today, you will not manage it on the worst day either.

When this is not your problem

If your guest Wi-Fi is a passphrase you change now and then, with no form and no logging, you do not have this risk. You have a different one — you do not know who connected — and in a small company with few visitors that is probably fine. Do not build a captive portal in order to comply better with a form you never needed: you will have created the database you do not currently have.

And we are not going to sell you a segmentation project for a guest router either. The expensive part of all this is not the technology: it is the inventory session, which is deathly boring and which nobody wants to do because it does not show. The technical part — one isolated VLAN, one scheduled deletion, two fewer fields on a form — is one of the few things in our trade that fits in an afternoon and does not break afterwards.

No system is secondary because of how little it does

That sentence is, at bottom, everything Zero Trust means once you strip off the vendor wrapping: nothing is trusted for being inside, for being small, or for having run four years without trouble. The guest portal is not trusted because all it does is hand out internet; the access point in the waiting area is not trusted because it sits on your own office ceiling. What decides the risk is not what the system does: it is what the system holds and what it is connected to.

In practice these are two jobs we always do together. The first is drawing the networks and communications properly, so the guest network sees nothing of yours. It is the same logic we apply to private carrier APNs: being "inside" is no guarantee of being alone either. The second is writing down the inventory of which data lives where, which is part of compliance and continuity and is the job nobody wants to do because it does not show.

Nobody is going to write an article about the day you deleted three thousand unused email addresses from a captive portal. It is the precise opposite of news. But if somebody does get in one day, the difference between your statement and somebody else's will be decided by what you did on that afternoon two years ago, not by what you buy on the day of the incident.

Sources (verified one by one): the literal quotes about the affected data ("car park, lounge and Fast Track bookings and in-airport WIFI sign-ups"), the four fields, the sentence stating that neither MAG nor the affected system held customers' bank or payment details, the temporary suspension of Manage My Booking and the statement that at no point was aviation security or airport operations compromised — Manchester Airports Group official statement. Coverage, context and dates — BleepingComputer, 27 August 2026 (also the source for the caveat that MAG contacted affected customers without publishing a figure and that the 8.9 million in local coverage rests on unconfirmed private statements) and Help Net Security, 28 August 2026. The ransom demand, MAG's refusal to pay it and the company saying it knows the identity of the group — statements to UK media reported, among others, by AeroTime. The data minimisation and storage limitation principles (Article 5(1)(c) and 5(1)(e)) — AEPD, GDPR principles; notification of a breach to the supervisory authority without undue delay and, where feasible, within 72 hours (Article 33) — text of Article 33 GDPR. All consulted on 29 August 2026. These are ours, and we flag them as judgement rather than published fact: the reading of the payments sentence as an architectural decision, the one about targeted fraud using number plates, the comparison between the operational criticality list and the data concentration list, and the six inventory questions.