Manchester Airport cyber attack: what to learn

What UK organisations can learn about staying secure

On 27 August 2026, Manchester Airports Group (MAG) confirmed that an unauthorised third party had accessed customer information relating to Manchester, London Stansted and East Midlands airports. The incident reportedly affected around 8.7 million customers, with information including email addresses, phone numbers, postcodes and vehicle registrations accessed.

MAG confirmed that banking and payment information was not held within the affected system and that airport operations, passenger safety and aviation security were not impacted.

While the scale of the incident makes headlines, there is a much wider issue for UK organisations to consider. You don’t need to operate an airport or hold millions of customer records to be exposed to cyber risk.

What would someone find in your systems?

Most organisations now rely on multiple pieces of technology to operate. That could include bespoke software, customer portals, booking platforms, websites, mobile apps, APIs, internal systems and older legacy applications that have been running for years.

Increasingly, it could also include tools created internally using AI.

Each of those systems may hold or have access to something valuable. Customer information, employee data, confidential documents, credentials, commercially sensitive information and intellectual property can all make an organisation attractive to attackers.

The Manchester Airports Group incident is also a reminder that information doesn’t need to include bank or card details to matter. An email address, phone number, postcode or vehicle registration may appear relatively harmless in isolation, but combining different pieces of information can make phishing, impersonation and social engineering attempts considerably more convincing.

Understanding what information your organisation holds, where it is stored and which systems can access it is therefore an important part of managing cyber risk.

Working software isn’t necessarily secure software

One of the challenges with software security is that vulnerabilities don’t always produce an obvious warning.

A customer can log in successfully. A booking can be completed. An API can return the right information and an internal system can work exactly as employees expect.

A vulnerability can still exist underneath it all.

Security weaknesses can be introduced through application code, authentication, APIs, configuration, exposed credentials or third-party dependencies. New risks can also be introduced as software changes.

This is why functional testing and security testing serve different purposes. Testing that an application works doesn’t necessarily tell you how it will behave when somebody deliberately attempts to exploit it.

For UK organisations operating their own software, an important question is therefore not simply “Does it work?”, but “Where could we be exposed?”

What can UK organisations do to stay safer?

There isn’t a single product or security measure that can guarantee an organisation won’t experience a cyber attack. Effective cyber security involves multiple layers, but visibility is an important place to start.

Organisations should understand what applications and systems they operate, what information those systems hold and who is responsible for maintaining them. This becomes increasingly important as businesses add cloud services, APIs, integrations and AI-generated tools to their technology stack.

Keeping software and dependencies updated is also important. Modern applications don’t consist solely of code written internally. They often depend on third-party packages, libraries and frameworks, and vulnerabilities discovered within those components can introduce risks into otherwise unchanged applications.

Organisations should also proactively look for vulnerabilities rather than waiting for an incident to reveal them. The UK’s National Cyber Security Centre recommends treating vulnerability management as an ongoing process: identifying vulnerabilities, understanding their significance and prioritising remediation.

That last point matters because simply producing a long list of potential security issues isn’t enough. Organisations need to understand which vulnerabilities present the greatest risk and what should be addressed first.

Security isn’t something you do once

Software doesn’t stand still.

New features are released, developers change code, dependencies are updated, APIs are introduced and new vulnerabilities are discovered. The application that was security tested six months ago may be substantially different today.

This is why vulnerability management shouldn’t be viewed purely as an annual compliance exercise or something considered immediately before launch. Regular security reviews and vulnerability scanning can help organisations maintain visibility as their software evolves.

Formal penetration testing also has an important role and may be required for certain organisations, customers or compliance frameworks. Automated vulnerability scanning isn’t a replacement for professional penetration testing, but it can provide another layer of security throughout the development and maintenance lifecycle.

Find vulnerabilities before someone else does

The Manchester Airports Group incident is still being investigated, and without confirmed technical information it would be wrong to speculate about exactly how attackers gained access or suggest that any particular security product could have prevented the incident.

What it does demonstrate is the potential scale of the consequences when somebody gains unauthorised access to a system containing valuable information.

UK organisations don’t need to wait for another major cyber incident before asking questions about their own technology.

• What software are we running?
• What information does it have access to?
• When was it last security tested?
• What vulnerabilities are currently sitting within it?

These are exactly the types of questions that led us to develop Hacka.

Hacka helps organisations and development teams analyse applications and codebases for potential security vulnerabilities, exposed credentials, vulnerable dependencies, supply-chain issues and other areas of risk. Findings are prioritised with remediation guidance so teams can understand what matters and what needs fixing.

Cyber security isn’t about assuming an attack will never happen. It’s about understanding your exposure, reducing unnecessary risk and making it harder for an attacker to succeed.

Know where you’re exposed. Fix what matters. Keep checking.