Manchester Airports Group Breach: The Data You Do Not Store Cannot Be Stolen
Manchester Airports Group has confirmed that an unauthorized third party obtained customer data connected to parking, lounge and Fast Track bookings and airport Wi-Fi sign-ups at Manchester, London Stansted and East Midlands airports. The accessed data includes email addresses, phone numbers, vehicle registrations and postcodes. MAG says neither it nor the affected system held customer bank or payment-card details, so those financial details were not exposed through this incident.
The breach is a practical demonstration of data minimization. Security controls can fail; an organization can still limit the consequence by not retaining sensitive fields in a system that does not need them.
What MAG confirmed
MAG says it contained the risk, restricted access to affected systems, engaged specialist advisers and notified relevant authorities. Passenger safety, aviation security and airport operations were not affected. Parking services and existing bookings continue to operate.
As a precaution, the online Manage My Booking service was temporarily suspended. MAG says it contacted affected customers directly and advises them to be alert for suspicious emails, text messages and calls. The company also states that it will never make an unexpected request for a password, payment-card number or banking information.
The Record reports that a company spokesperson put the affected population at roughly 8.7 million people and said that, in the vast majority of cases, only an email address was accessed. That figure and distribution do not appear in MAG's public incident page, so they should be treated as reported through a spokesperson rather than as a number in the formal notice.
No payment data is a design outcome, not good luck
A breach does not expose every field an organization has ever processed. It exposes what the attacker can reach in the affected environment. MAG's statement says the relevant systems did not hold bank or payment details. That decision removed an entire category of high-impact data from this incident's blast radius.
The same design question applies to secrets. Does a booking platform need a reusable support password? Does a vendor need a permanent export token? Does a ticket need the customer's full credential, or only a reference to a time-limited handoff? If the answer is no, keeping the value out of the system is stronger than relying on another database permission to protect it forever.
Contact data still creates a convincing phishing kit
Email addresses, telephone numbers, postcodes and vehicle registrations are not payment credentials, but together they can make a fraudulent message feel specific. A criminal could reference an airport, parking booking, car or locality and claim that payment, rebooking or identity verification is urgently required.
The temporary suspension of Manage My Booking also creates a believable pretext: a scammer can claim the normal service is unavailable and direct the customer to a replacement link or phone number. Affected customers should start from the airport's official website or a previously saved booking confirmation, not from a link or number in an unsolicited message.
A safer data-minimization checklist
- Map every collected field to a current purpose. Remove values retained only because they might be useful later.
- Separate operational data from payment data. Tokenize or delegate payment processing instead of copying card details into booking systems.
- Set deletion rules for vendors and exports. A retention policy must cover processors, backups and support tooling—not only the primary database.
- Use references instead of plaintext secrets. Tickets and chats should point to a controlled transfer, not contain the password or recovery value.
- Prepare an anti-phishing message. State clearly what the organization will never request and where customers can verify updates.
- Test degraded customer journeys. If a booking portal is offline, publish one verified alternative before scammers invent several.
Where Secretus fits
Secretus can reduce permanent copies when an authorized support or incident-response team must transfer a password, API key or temporary recovery value. A one-time link with a short expiration keeps the plaintext out of the email or ticket body. Team Split can add multi-person control where one operator should not be able to release a critical secret alone.
Secretus is not a storage-retention program and does not make an unsolicited message trustworthy. The sender and recipient still need independent verification, and the secret should be opened only on a known-clean device. After the immediate task, revoke temporary access and remove unnecessary copies from the surrounding workflow.
What remains unknown
MAG has not publicly disclosed the initial access vector, the exact affected system, a detailed date range or whether every listed data type was present for every person. The public notice does not identify an attacker or claim ransomware. Those gaps should not be filled with speculation. The confirmed lesson is already strong: data minimization limited what this particular system could give away.