Your next procurement decision for any system that issues, stores or verifies aviation certificates comes down to one question: does the proof survive the loss of the system itself — or does your chain of documentary evidence die with your IT? The answer should be that verification must remain possible with the issuer's servers offline, the vendor's backend compromised, and your own information system encrypted; this article lays out the August 2026 threat signal, a survivable-proof checklist you can apply to every certificate system you operate or buy, and the one architectural property that makes the difference.

The signal: aviation is now a named target

On Monday, August 10, 2026, the UAE Cybersecurity Council announced via the state news agency WAM that national defense systems had detected and repelled "advanced and organized cyberattacks targeting the aviation, energy and education sectors in the country." The council said the intrusion attempts were contained before any systems were disrupted or data compromised, and — consistent with its practice — assigned no attribution.

Two features of the announcement matter for aviation operators far beyond the Gulf. First, this was not an isolated event. It was the third publicly disclosed critical-infrastructure campaign against the UAE in 2026: a February wave the council described as involving ransomware deployment and AI-enhanced offensive tools, a July campaign against the financial sector, and now aviation, energy and education. The progression is toward broader sector coverage, not away from aviation. Second, the attack architecture the council described — simultaneous infrastructure breach attempts, targeted campaigns against operational accounts, and coordinated phishing — is aimed at exactly the layers where maintenance, quality and training records live: operational systems and the credentials of the people who use them.

The background numbers give the scale. Before the 2026 regional conflict escalated in late February, UAE systems absorbed between 90,000 and 200,000 breach attempts per day; after military operations began, the figure surged to between 600,000 and 800,000 daily attempts, according to UAE cybersecurity officials cited by Dark Reading and relayed by Tech Times. A four-to-eight-fold increase in attack volume on one country's infrastructure is not a Gulf-specific story; it is an indicator of what a mobilized threat environment looks like.

Daily breach attempts against UAE systems Before the late-February 2026 escalation 90,000-200,000 / day After military operations began 600,000-800,000 / day A four-to-eight-fold increase in attack volume
Volumes cited by UAE cybersecurity officials, relayed by Dark Reading and Tech Times; bars are scaled to the top of each range.

And the industry has already run the live exercise of what a successful attack does. On the evening of Friday, September 19, 2025, a ransomware attack on Collins Aerospace's MUSE check-in and boarding software disrupted London Heathrow, Brussels and Berlin Brandenburg airports, with Dublin and Cork also affected. Airlines reverted to manual check-in and baggage handling; Brussels Airport asked airlines to cancel half of their departures to manage the backlog. The UK's National Crime Agency arrested a suspect in West Sussex on September 23, and the Everest ransomware group later claimed responsibility. The World Economic Forum's post-incident analysis of September 25, 2025 drew the structural conclusion: a single shared vendor constituted a single point of failure that disrupted physical operations across multiple countries for days.

The WEF analysis contains the figure that should sit in every aviation risk register: the Forum's "Global Cybersecurity Outlook 2025" found that 54% of large organizations identify supply-chain complexity as one of the biggest barriers to cyber resilience — limited visibility into suppliers, uneven capabilities across them, and cascading dependencies. Aviation is the extreme case of that pattern: a small number of niche, critical vendors whose failure propagates instantly.

Sep 19, 2025 Collins Aerospace ransomware disrupts European airports Feb 2026 UAE wave with ransomware and AI-enhanced attack tools Jul 2026 UAE campaign targets the financial sector Aug 10, 2026 Attacks on aviation, energy and education repelled
The third publicly disclosed UAE critical-infrastructure campaign of 2026 — and the first to name aviation.

The blast radius nobody budgets for: your proof of airworthiness lives in the attacked systems

The Collins Aerospace coverage focused, understandably, on stranded passengers. But check-in systems are not the only aviation IT that ransomware reaches. The same attack profiles target the systems that hold the documentary evidence of airworthiness: MRO and continuing-airworthiness management platforms, quality management systems, learning management systems that issue Part-147 training certificates, electronic technical logbooks, and the document management systems where Form 1s, 8130-3s and Authorized Release Certificates are archived.

Consider what those systems contain from a regulator's or an auditor's perspective. An EASA Form 1 or FAA 8130-3 is not a courtesy document: it is the legal assertion that a part was produced or maintained in accordance with approved data — the same class of proof we examined when GA Telesis put parts traceability on a blockchain. The complementary lesson from AOG Technics three years on is that a certificate the receiver cannot verify independently is a systemic risk, whether the failure mode is forgery or the issuer's systems going dark. A Part-147 attestation is a different kind of record — evidence that a person completed approved training or passed an examination, not, by itself, proof that they were authorized to certify work: as the EASA's Part-147 FAQ and its FAQ on Part-66 licence privileges make clear, certification privileges rest on the Part-66 licence and on the certifying-staff authorization issued by the maintenance or continuing-airworthiness organization (Part-145 or Part-CAMO), so a Part-147 training certificate alone does not establish certification privileges. A repair station's capability list defines what it is approved to touch. Every one of these assertions — and the training and qualification records behind them — may need to be proven — to an authority during an audit, to an operator during a pre-purchase inspection, to an insurer or a court after an incident — years after issuance, by someone who was not in the room.

Now run the incident. Three failure modes, in increasing order of severity:

  • Availability loss. Your MRO or quality platform is encrypted or offline for days to weeks — the Collins outage lasted days at a vendor with world-class incident response. During that window, can you demonstrate to an auditor that a certificate issued three years ago is authentic? If verification means logging into the platform that is down, you cannot. The certificates still exist; their provability does not.
  • Integrity loss. This is the scenario that keeps investigators employed: the attacker does not encrypt the records, they alter them. A part status changed, a life-limited component's history edited, a training record backdated. If your proof of what a certificate said is a row in the same database the attacker controlled, you have no independent reference to prove the alteration happened. The backup restores the database — possibly including the attacker's edits, if they predate the backup window.
  • Vendor mortality. Collins Aerospace survived. Smaller vendors do not always: ransomware events routinely end in bankruptcy, acquisition, or quiet sunsetting of a product line. If your verification path runs through a vendor API that no longer exists, every certificate whose proof depends on that API becomes unverifiable retroactively — not because anything was forged, but because the checking mechanism died with the company.

The common thread is architectural, not operational. In all three scenarios the document itself can be perfectly preserved — a clean PDF in your own DMS — and still be unprovable, because provability was outsourced to a system that failed. The question "can you prove it?" collapses into "is that system up, uncompromised, and still in business?" That is a dependency no quality manual should accept for safety-critical evidence.

What survivable proof actually means

The fix is a property, not a product category: verification that is independent of every party whose failure you are insuring against. Concretely, a certificate proof is survivable when it has four properties.

First, the proof is anchored at issuance. At the moment the certificate is created, a cryptographic fingerprint of the exact document — its SHA-256 hash — is recorded somewhere the issuer does not control. Anything anchored later, or reconstructible only from a live database, is a weaker claim: it proves what the database says now, not what the certificate said then.

Second, the anchor lives on infrastructure no single party can switch off or rewrite. A public, append-only ledger is the practical implementation: no vendor outage, ransomware event or bankruptcy can erase or edit a confirmed entry, and no single administrator can alter it retroactively.

Third, verification is permissionless and client-side. Whoever holds the document — an auditor, a receiving inspector, an opposing expert in litigation — recomputes the hash locally and queries the ledger directly. No account, no API key, no call to the issuer's servers, no call to the platform vendor. The verifier's only dependencies are the document in hand and read access to a public network.

Fourth, the anchor is hash-only. The ledger stores the fingerprint, never the document content. That is what sharply reduces the exposure of confidential maintenance data and personal data in training records, and it is the kind of architecture that can support a GDPR compliance posture: verification reveals nothing about the certificate's content to anyone who does not already hold it, and the organization keeps full control of disclosure. It is not, by itself, a guarantee of GDPR compliance — lawful basis, retention and erasure obligations still apply to the systems that hold the underlying documents.

These four properties are precisely what the manual fallback during the Collins incident lacked. Airports could revert to paper check-in because a boarding pass is self-contained evidence. Aviation certificates can enjoy the same property — a document that carries its own independently checkable proof — but only if the proof architecture was designed for the day the system fails, not for the day everything works.

The tool: the survivable-proof checklist

Translated into what a quality director, CAMO manager or MRO procurement lead can actually ask — of their own systems and of every vendor proposal. Any "no" is a finding.

  1. Can a third party verify a certificate without contacting you? If checking requires a phone call, an email to the issuing shop, or a login to your portal, the proof depends on your availability and your good faith. Survivable proof answers strangers.
  2. Can a third party verify without contacting the platform vendor? Same test one level down. If verification routes through the vendor's API or hosted verifier, a vendor outage — the Collins scenario — blinds every certificate issued through that platform, worldwide, simultaneously.
  3. Was the proof anchored at issuance? Ask to see the timestamp evidence for a certificate issued three years ago, and ask whether that timestamp could be recomputed from anything other than the immutable record itself. "Our database records the creation date" is the wrong answer: the database is the thing being attacked.
  4. Is the integrity reference stored outside your administrative control? If the same administrator (or the same attacker with the admin's credentials) can modify both the certificate and its integrity reference, the reference proves nothing. The anchor must live where your own root credentials do not reach.
  5. Does verification work from the document alone? The auditor of the future holds a PDF or a printed page. If proof requires the original system, the original file format, or the original vendor's software, the proof has a shelf life tied to that software.
  6. What exactly is on the shared infrastructure? Hash-only anchoring means confidentiality survives verification. If the design puts document content or personal data on shared infrastructure, you have traded an integrity problem for a confidentiality one.
  7. Does the verification payload live in your own DMS? The document plus its verification link or QR code should be archived with your records, under your retention policy — so the proof travels with the record through vendor changes, migrations and bankruptcies.
  8. Have you tested the failure? Once a year, pick a certificate at random and verify it with your quality system offline, from a clean machine, the way an external auditor would. A proof chain that has never been exercised in degraded mode is an assumption, not a control.

This list is deliberately procurement-shaped: every item becomes a requirement clause in a specification or a question in a vendor due-diligence questionnaire. Nothing on it requires buying anything new to start asking.

Three clauses you can paste into a specification

The FAQ's three requirements, written so a procurement lead can drop them into an RFQ without translation.

  1. Independent verification. Any third party holding the issued document shall be able to verify its integrity and issuance timestamp without contacting the issuer, without creating an account, and without calling any API operated by the issuer or by the platform vendor.
  2. Anchor at issuance. The integrity reference shall be recorded at the moment of issuance on infrastructure the issuer does not administratively control. A creation date stored in the issuer's or vendor's database is not an integrity reference.
  3. Payload in the customer's DMS. At issuance, the customer shall receive an exportable verification payload (the document plus its QR code, link or equivalent) that can be archived in the customer's own document-management system. Verification shall remain possible from that payload after the vendor contract ends.

If a proposal cannot accept all three in writing, treat the gap as a finding, not as a negotiation on wording.

The bounded case: one training certificate through a ransomware event

A mid-size Part-147 maintenance training organization issues a type-rating certificate to a mechanic in March 2023. In October 2026, ransomware encrypts the organization's LMS and quality management system; the attacker exfiltrated data first and threatens to leak it. Six weeks later, an EASA standardization audit asks the organization to demonstrate the qualification basis for a sample of certifying staff — including that mechanic.

StepCertificate in the internal databaseCertificate anchored at issuance
Evidence at issuanceA row in the LMS database; PDF generated from itThe PDF's SHA-256 hash recorded on a public ledger at issuance; PDF + verification QR archived in the DMS
State after the attackDatabase encrypted; restored-from-backup copy is now the only "truth," with no independent way to show the row was not altered before or during the incidentThe 2023 anchor is untouched — it lives where neither the attacker nor the organization's own admins can edit it
Demonstration to the auditorExport the row, print the certificate, assert integrity; the auditor must trust the system that just failedThe auditor recomputes the PDF's hash on their own machine and queries the ledger directly: the exact document existed, unmodified, in March 2023
If the record was tamperedUndetectable against a compromised primary system; the backup may contain the tampered versionThe recomputed hash no longer matches the anchor — the alteration is provable, not just suspected
If the LMS vendor later failsVerification path dies with the vendor's APIVerification depends only on the document and public read access to the ledger

Two properties of the anchored column deserve emphasis. The proof is retrospective without being retroactive: it protects only what was anchored at the time, but once anchored, it keeps protecting through any later incident. And the demonstration is self-service for the auditor: nothing in the right-hand column requires the training organization's systems, staff or cooperation to be available — which is exactly what makes it evidence rather than testimony.

What this does not solve

Precision about limits is what separates an architecture decision from a marketing claim. Five of them.

  • Anchoring does not prevent the attack. It is not a security control in the preventive sense. Patching, segmentation, phishing-resistant authentication, backups and incident response remain the layers that keep you out of the incident; the UAE council's own directive — comply with controls, keep systems updated, report suspicious activity — is unchanged. Anchoring determines what is still provable after those layers fail.
  • It does not restore operations. The Collins incident's cost was operational: queues, cancellations, manual fallback. No proof architecture shortens that. The value case is different: the integrity and timestamp of your documentary evidence stop being part of the blast radius.
  • History is not retroactively protected. Anchoring protects certificates issued after adoption. A decade of legacy records can be re-anchored today, but that proves only that they existed unmodified as of today — it cannot prove they were not altered at some earlier point. The value of adoption compounds with time and cannot be bought back later; that is an argument for deciding now, not a claim that deciding now fixes the past.
  • Garbage in, garbage out. An anchor proves a document was not altered after anchoring. It cannot prove the content was true at issuance: a false certificate anchored honestly is still false. Issuer identity, accreditation and audit remain the first line — anchoring raises the cost of undetectable forgery from database access to compromised issuance, not to zero.
  • The ledger is a dependency too. Verification reads a public network; a verifier needs the document, its payload, and read access to the chain. In a fully offline scenario — a tarmac, a hangar Faraday cage — verification waits for connectivity. The honest claim is independence from the issuer's and vendor's infrastructure, not from infrastructure altogether.

The discipline these limits impose is simple: survivable proof is the resilience layer for documentary evidence. It complements cybersecurity; it does not substitute for it.

AeroCert's take

AeroCert's take: August 10, 2026 is the date aviation stopped being adjacent to sectoral cyber campaigns and became a named target in one — and the Collins Aerospace weekend eleven months earlier showed what a single vendor failure does to operations that assumed their systems would be there. The same assumption is embedded, unexamined, in how the industry keeps its proofs: certificates whose verification depends on the issuer being reachable, the vendor being solvent, and the database being honest. We build the alternative: every certificate issued through AeroCert has its SHA-256 hash anchored on the Avalanche blockchain at issuance, and verification is anonymous and backend-independent — scanning the QR code recomputes the hash client-side and reads the on-chain registry directly, with no account and no call to any AeroCert server, while the backend itself never sees clear certificate data, only hashes and encrypted payloads. The question for your next audit, incident or dispute is not whether your certificates exist; it is whether anyone can still prove them when your systems cannot help. See how AeroCert verification works, or run the architecture against your own requirements on the developer platform.

Sources