Under the NIS2 Directive, air carriers are essential entities. The directive requires them to implement appropriate technical measures to manage cybersecurity risk, including encryption and secure communications. The question we set out to answer is simple: how close are Europe’s airlines to meeting that standard? We started with Aer Lingus, an IAG subsidiary carrying 11 million passengers a year across Europe and the Atlantic.
What we found is not a borderline case. Every booking on aerlingus.com transmits passport numbers, dates of birth, nationalities, and travel itineraries. The TLS configuration protecting that data still negotiates 3DES, still supports TLS 1.0, and has never been upgraded to TLS 1.3. This is not a configuration that is close to compliant and needs a few adjustments. It is a configuration that has not been meaningfully updated in years, running on a platform that could do better tomorrow.
SSL Labs grades aerlingus.com a B. pqprobe grades it an F. Both are correct — they measure different things. The B reflects classical TLS weaknesses: TLS 1.0 and 1.1 still enabled, 3DES still offered. The F reflects a complete absence of post-quantum protection. If this is what an essential entity in the EU transport sector looks like seventeen months after the NIS2 transposition deadline, the directive has a compliance gap that extends well beyond one airline.
What the grades actually mean
SSL Labs evaluates classical TLS security: certificate validity, protocol support, cipher strength. Aer Lingus still supports TLS 1.0 and TLS 1.1, which caps it at B. That B is generous. TLS 1.0 was a known-vulnerable protocol when POODLE hit in 2014. PCI DSS required migration off it by June 2018. Every major browser announced deprecation in 2018 and completed rollout by mid-2020. RFC 8996 formally deprecated both in 2021. Running TLS 1.0 on a customer-facing site in 2026, five years past formal deprecation, is not a minor protocol version penalty. It’s a configuration that no site collecting identity documents should still be running. SSL Labs caps it at B. The real question is why it isn’t lower.
pqprobe asks a different question: what happens to this traffic when a cryptographically relevant quantum computer arrives? The answer, for aerlingus.com, is that nothing in the configuration is quantum-safe. The ECDHE-RSA suites provide forward secrecy against classical attacks, but the ephemeral ECDH keys (on P-256) are vulnerable to Shor’s algorithm. The bare RSA suites are worse: TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, and the infamous TLS_RSA_WITH_3DES_EDE_CBC_SHA have no forward secrecy at all. An adversary who records these sessions today and later factors the server’s RSA key can decrypt every one of them. That is the harvest-now-decrypt-later scenario in its purest form. There is no post-quantum cryptography. There is no hybrid key exchange. There is no TLS 1.3, the prerequisite for PQC key agreement in any current implementation. The pqprobe scan grades this an F, and it’s hard to argue otherwise.
The platform isn’t the problem
Aer Lingus runs on AWS. The SSL Labs report identifies the server as awselb/2.0, an AWS Application Load Balancer in eu-west-1. AWS ALBs have supported TLS 1.3 since 2023. AWS now offers post-quantum TLS policies for ALBs (ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09), supporting hybrid ML-KEM key exchange. Aer Lingus could have PQC on the same load balancer today. This isn’t a case where the underlying platform can’t do better. It’s a configuration choice.
The handshake simulation in the SSL Labs report shows who that choice serves: Android 2.3.7, which hasn’t received a security patch since 2011. IE 8 on Windows XP, which negotiates 3DES with no forward secrecy. Java 6u45, end-of-life since 2013. These are not “legacy clients.” These are devices with known, unpatched vulnerabilities that cannot protect the sessions they establish, even with the weak encryption the server agrees to speak. Accepting connections from systems that have had no security updates in over a decade is not backwards compatibility. It is the equivalent of letting people ride horses on highways among modern cars, just because they have saddles.
PCI compliance is not a cryptographic strategy
An airline that accepts credit cards online must comply with PCI DSS. Under PCI DSS 4.0, TLS 1.0 is classified as “early TLS” and is not considered strong cryptography. 3DES does not meet PCI DSS 4.0’s definition of strong cryptography. Aer Lingus still offers TLS_RSA_WITH_3DES_EDE_CBC_SHA in its cipher suite list.
How does this work? Aer Lingus built a bespoke payments hub that routes card processing through external payment service providers: Revolut Pay, Apple Pay, Google Pay, PayPal, and traditional card acquirers. According to the published architecture, card numbers are not expected to touch the aerlingus.com TLS stack directly. The PSP handles the PCI-scoped transaction. This is a legitimate architecture and a common pattern in the airline industry.
But PCI DSS only protects one data type: the primary account number. Everything else an airline collects (and airlines collect a lot) is outside PCI scope entirely.
What actually flows over that TLS 1.0 connection
When you book a flight on aerlingus.com, you provide your full legal name, date of birth, passport number, nationality, email address, phone number, billing address, and travel itinerary. If you’re an AerClub member, your loyalty profile and travel history are attached. For transatlantic flights, advance passenger information includes passport expiration dates and issuing country.
All of this transmits over the same TLS stack that SSL Labs graded B. The same stack that still negotiates 3DES. The same stack with no TLS 1.3 and no post-quantum protection of any kind.
This is high-value data for harvest-now-decrypt-later collection. An adversary recording TLS sessions today doesn’t need to break the encryption now. Names, dates of birth, and nationalities never expire. Passport numbers are reusable for identity fraud long after the document itself is replaced. Travel patterns have intelligence value indefinitely. Unlike a credit card number that can be revoked and reissued, identity data cannot be rotated.
GDPR Article 32 and the meaning of “state of the art”
The General Data Protection Regulation requires controllers to implement “appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art.” Article 32 explicitly names encryption as an example measure. The EDPB has clarified that existing standards and frameworks indicate the current state of the art, and controllers should take them into account.
TLS 1.0 is not state of the art. It was deprecated by RFC 8996 in 2021. 3DES is not state of the art. It was removed from NIST’s approved algorithms. BSI TR-02102 does not recommend either. No credible security framework published in the last five years considers this configuration appropriate for protecting personal data in transit.
Aer Lingus is part of the International Airlines Group. IAG has direct experience with GDPR enforcement. The ICO fined British Airways £20 million after finding it had processed personal data without adequate security measures, measures that were available at the time. That is not a distant precedent. It is the same corporate group. Under NIS2, the exposure is larger: fines reach €10 million or 2% of global annual turnover. Ireland’s transposition is underway.
“Aerlingus.com is secure”
Aer Lingus publishes a “Stay Safe Online” page advising customers to “only provide this information over encrypted websites” and to “look for ‘https’ at the beginning of the web address.” The company’s login pages display the statement: “Aerlingus.com is secure. We treat your personal data with care.”
That assurance is served over a TLS stack that negotiates 3DES, supports TLS 1.0, and has no TLS 1.3. By the standards of every major security framework (PCI DSS, NIST, BSI, ENISA) this is not a secure configuration. Telling customers to trust HTTPS while serving deprecated cryptography is not just ironic. It may be actionable.
The EU’s Unfair Commercial Practices Directive prohibits misleading commercial practices. Article 6(1) covers actions that deceive the average consumer about “the main characteristics of the product,” including its risks and fitness for purpose. Article 7 covers misleading omissions — failing to disclose material information that the consumer needs to make an informed decision. Telling customers a site is secure, while operating a TLS configuration that every relevant authority has deprecated, could engage either provision. Ireland transposed the Directive into the Consumer Protection Act 2007, which carries criminal penalties for certain offences.
Customers are told to look for the padlock. The padlock is there. What’s behind it is a cipher so old it’s like selling a ticket to a modern jet flight and then boarding an old prop plane.
Two grades, one trajectory
The SSL Labs B and the pqprobe F measure different things. One measures where we have come from and the other measures where we are going. Both measurements are accurate. But together they reveal something that neither shows alone: an organization that has not meaningfully updated its TLS configuration in years, that is still serving deprecated cryptography to devices too broken to protect the sessions they establish, and that has no visible path toward post-quantum readiness.
Some may still be asking when aerlingus.com will transition to support TLS 1.3 and hybrid PQC key exchange. The answer is someday, and it can’t be soon enough. The better question is who is liable for passport numbers, travel patterns, and identity data flowing on a dangerously deprecated configuration — and whether the harm can be undone when a transition finally happens.