AOMEI Backupper is backup software, the kind of tool procured once, configured once, and then forgotten, because forgetting about it is the point. Between April and July 2026, attackers altered two configuration files on AOMEI’s own update servers, down_html.ini, which tells the software where to download updates and what checksum to expect, and Notifycfg.ini, which controls the pop-up notifications that can trigger code execution. They supplied a matching checksum so the malicious package passed verification, then restored the original files within minutes. Confirmed tampering lasted roughly ten minutes on 28 May, six minutes on 16 July, and five minutes on 20 July. Any copy of the software checking for updates during one of those windows received a dropper called CROSSROAD, which in turn installed a legitimate remote access tool, Radmin, alongside a backdoor named SHINYROAD. On 20 July, a fourth technique tried to steal Windows password hashes by forcing machines to authenticate to an attacker controlled server, no malware required.

The Vendor Didn’t Believe Its Own Customers

ManageEngine’s endpoint detection software flagged the Radmin installation at two unrelated customers on 28 May. A customer raised the alert on 7 June, and ManageEngine told AOMEI that same day. AOMEI’s own account of what happened next is the part worth sitting with. It initially said the content had been intercepted and altered in transit, not on its own servers. ManageEngine disputed this, and said the evidence pointed to the vendor’s own delivery path. AOMEI investigated, said it had patched unspecified vulnerabilities, and could not identify a root cause. The attackers struck twice more, on 16 July and 20 July, while AOMEI believed the matter was closed. AOMEI only found traces of the intrusion after Mandiant and ManageEngine handed it the exact timestamps of the July windows. As of the most recent reporting, AOMEI had not identified or notified the customers whose machines were compromised.

This Is Not a Cybersecurity Story First

Treat this as an availability incident and the lesson is patch management. Treat it as what it actually is, a vendor trust failure in a category of software built entirely on trust, and the lesson changes. Backup software exists to be the thing an organisation reaches for when everything else has gone wrong. It runs with elevated privileges, it phones home for updates by design, and it rarely gets the scrutiny applied to software that actually touches customer data, precisely because it sits one layer removed from the systems everyone assumes carry the real risk. A PMO that tracks vendor risk at the point of procurement and never again has already missed where this incident happened. AOMEI was told directly, in June, that its update path had been compromised, and still could not confirm the problem was fixed before it recurred in July.

What a Governance Review Should Actually Ask

The question for any PMO or transformation office is not whether an organisation runs backup software from a reputable vendor. Every organisation does. The question is who owns the relationship with that vendor once the contract is signed, and whether that owner has a standing channel to hear about an incident like this one within days rather than months. Three things are worth checking this week. Does the vendor risk register include infrastructure tools that run with elevated privileges but rarely get named in a security review. Does the incident response plan assume a vendor will report promptly when its own update mechanism fails. Has anyone asked the backup vendor directly, this year, how it verifies the integrity of what it pushes to company machines.

The Software You Forgot About Is Watching Your Network Right Now

AOMEI has released a free detection tool and is urging customers to update and scan. That response arrived months after the first warning, and only after outside threat intelligence teams handed the vendor the exact minute its own servers were compromised. Pick the vendor in your own environment that nobody has reviewed since the contract was signed. Name who owns that relationship now, and ask whether they would know within a week if it failed the way AOMEI’s did.

Fifty three percent of connected medical devices and other IoT devices in hospitals carry at least one known critical vulnerability, a 2022 finding from Cynerio’s device-security research that the FBI also cited in its own 2022 industry notification. The technical frameworks for fixing that have never been more developed. The FDA’s final cybersecurity guidance is in force, the Software Bill of Materials requirement exists, and postmarket management obligations are written down in detail. The vulnerability rate has not moved because the problem was never a shortage of frameworks. It is a shortage of accountability.

Where the Failure Actually Happens

Devices that harm patients through cybersecurity failures are almost never the ones designed insecurely from the start. They are devices whose security posture was adequate at launch and then allowed to degrade, because inside the manufacturer’s organisation, nobody has clear ownership of whether an upstream vendor’s patch gets evaluated, prioritised and deployed. Fresh 2026 breach data from ORDR’s medical device security report puts a sharper edge on this: 99% of hospitals now manage at least one connected device with a known exploited vulnerability, and 60% of medical devices in service are end-of-life systems with no security patches available at all. Claroty’s 2025 State of CPS Security research sharpens that picture at the device level: 28% of imaging devices and more than 70% of patient devices already carry vulnerabilities that attackers are actively exploiting. That is a governance choice made, and remade, every time a patch review gets deprioritised, rather than a purely technical shortfall.

The Consequence Is Already Measurable

The clinical cost of that choice is no longer abstract. RunSafe Security’s 2026 industry survey found that 24% of healthcare organisations experienced a cyberattack or exploited vulnerability affecting a medical device in the past year, with 80% of those organisations reporting moderate or significant patient care impact and nearly half reporting extended stays and manual clinical workarounds. Separate 2026 reporting on the sector’s threat landscape found that 22% of healthcare organisations had already faced at least one medical device cyberattack that year, consistent across both surveys despite different methodologies. The chain of decisions behind such an incident runs through a manufacturer’s governance structure long before it reaches a hospital network team.

What Procurement Is Already Doing About It

Health systems have stopped waiting for manufacturers to fix this voluntarily. RunSafe’s survey found that 84% of healthcare organisations now write cybersecurity requirements directly into vendor RFPs, more than half have already rejected a device on cybersecurity grounds, and 81% rate a Software Bill of Materials as having strong influence or essential value in a purchasing decision. The SBOM is a useful test case for the whole argument: it is a list of components with version numbers, and its entire value depends on whether anyone inside the manufacturer actually monitors those components for newly disclosed vulnerabilities. A manufacturer that produces an SBOM and never checks it against new advisories has completed the paperwork without doing the work.

The Governance Architecture Most Organisations Still Lack

The FDA’s final guidance on cybersecurity in medical devices, effective from 27 June 2025, treats cybersecurity as a design and quality system requirement running across the whole product lifecycle, not a one-time premarket check. Meeting that standard requires a named owner for postmarket vulnerability management, a defined severity and patch-priority process, a published disclosure policy, and a board that understands cybersecurity as an ongoing lifecycle obligation rather than a launch-day certification. The manufacturers facing the sharpest regulatory and reputational exposure will typically be the ones that built adequate devices and then failed to govern what happened next, rather than the ones that built insecure devices in the first place.

Where to Start This Quarter

A board can test this in one question: who owns postmarket vulnerability management for every device category currently in service, by name, with a published patch-priority process behind it. Manufacturers that can already answer, with an SBOM someone actually monitors rather than merely files, are the ones procurement teams are choosing to buy from. That question costs nothing to ask. Answering it honestly, rather than deferring it to the next audit cycle, is the actual compliance work, everything else on the checklist is paperwork around it.

Cloud misconfiguration accounted for 14 per cent of confirmed breaches globally in the first quarter of 2026, up from 9 per cent in 2024, according to security analysis built on Verizon’s Data Breach Investigations Report (DBIR). It has not overtaken vulnerability exploitation as the leading cause of breaches overall, but it is the fastest-growing technical vector in the data, and the gap between how many organisations use multiple clouds and how many can actually secure them consistently is the reason why.

An Old Problem Getting Worse, Not Better

More than three quarters of organisations now run multiple cloud providers, and 66 per cent of them say maintaining consistent security controls across those environments is genuinely difficult. Nearly a third of cloud resources go unmonitored entirely, carrying an average of 115 unpatched vulnerabilities each, and the average configuration issue sits undetected for around 180 days before anyone finds it. Multi-cloud strategy has become standard practice faster than the tooling and staffing needed to secure it consistently, and 45 per cent of organisations admit they simply do not have adequate staff for the challenge.

What This Actually Looks Like

The consequences are not hypothetical. One documented incident exposed personal data and location details for 2.15 million connected vehicle users, left publicly accessible for nearly a decade because of a single unaddressed misconfiguration. Another exposed 38 million personal records, names, emails and phone numbers, across 47 separate organisations, including government agencies, through one configuration error in shared enterprise software. Neither incident required a sophisticated attacker. Both required someone to notice a setting that had been wrong for years.

A Global Technical Problem, Uneven Regulatory Response

This is not a story about one cloud provider or one region. AWS, Azure and Google Cloud environments all appear in the underlying breach data, and the DBIR’s own methodology draws on incidents reported by law enforcement agencies and computer emergency response teams worldwide. The regulatory response so far is patchier than the problem. The US has moved furthest, with Cybersecurity and Infrastructure Security Agency (CISA) mandating federal agencies secure their cloud environments to a defined standard, but most jurisdictions still treat cloud misconfiguration as a subset of general data protection obligations rather than a distinct, named risk category with its own enforcement expectations.

What a PMO Should Actually Check

A technology steering committee reviewing cloud risk should ask a narrower, more useful question than whether cloud security policies exist. It should ask what percentage of cloud resources are actively monitored right now, how long a misconfiguration typically sits before detection in this specific environment, and whether that number has ever been measured at all. A policy document proves intent. It does not prove that a setting exposing 2.15 million users has not been sitting open for years. Multi-cloud strategy delivered real flexibility. The security discipline to match it is still, for most organisations, a work in progress rather than a finished job.

Somewhere right now, encrypted data belonging to your organisation is very possibly being copied and stored by someone who cannot read it yet. That is the entire premise of harvest now, decrypt later, and two governments have just put binding migration deadlines around the assumption that this is already happening.

The Threat Nobody Can See Happening

Harvest now, decrypt later works in three stages: an adversary intercepts and stores encrypted traffic today, holds onto it, and waits for quantum computing to mature enough to break the encryption later. The NSA, CISA and NIST have all warned that this is already happening rather than a future scenario, with government communications, healthcare and genomic records, financial transaction histories and long-lived proprietary research flagged as the categories of data most exposed, precisely because their value does not expire when the encryption eventually does. The unsettling part is that an organisation has no way of knowing whether its own traffic has already been harvested. There is no breach notification for data that was quietly copied rather than stolen outright, years before anyone could do anything with it.

Two Governments, Two Deadlines, One Shared Conclusion

The United States moved first. NIST finalised its first post-quantum cryptography standards in August 2024, and the NSA’s CNSA 2.0 framework now requires quantum-safe algorithms on all new national security systems from January 2027, full application migration by 2030, and complete infrastructure migration by 2035. The UK’s National Cyber Security Centre published its own roadmap in March 2025, structured differently but arriving at the same endpoint: identify and plan by 2028, execute high-priority upgrades between 2028 and 2031, and complete migration across all systems, services and products by 2035. Two governments, working independently, converged on the same twenty-year horizon and the same conclusion that this cannot be left until quantum computers actually arrive.

Why the Slow Timeline Is the Argument, Not the Excuse

It would be easy to read a 2035 deadline as a reason to defer this for years. That reading gets the risk backwards. Cryptographic migration across a large organisation’s systems, vendors and data stores typically takes five to ten years to execute properly, which means an organisation starting its inventory and planning today is already working to a tight schedule against either government’s timeline, rather than a comfortable one. Industry analysts project the post-quantum cryptography market will exceed 15 billion dollars by 2030, and enterprises are being advised to allocate 2 to 5 per cent of annual security spend to migration over a four-year window. The bottleneck was never algorithm development. NIST has already published the standards. The bottleneck is inventory, sequencing and the unglamorous, multi-year discipline of finding every system that needs to change.

What a PMO Should Do With This Now

Post-quantum migration belongs on a technology roadmap as its own workstream, rather than folded quietly into general infrastructure refresh budgets where it will lose priority against anything more visible. The first deliverable is not a pilot project. It is an inventory: which systems, vendors and data categories carry encryption that needs to survive into the 2030s, ranked by how long that data needs to stay confidential. Anything meant to remain secret beyond 2030 is already, by definition, running on borrowed time.

On 19 September, the extortion group ShinyHunters broke into the dark web leak site run by Cl0p, one of the most prolific ransomware operations of the past two years, and defaced it. Three days later Cl0p was still trying to regain control, and every company that quietly paid Cl0p to make a breach disappear had a new, uncomfortable question to answer.

What ShinyHunters Actually Took

ShinyHunters exploited an unauthenticated file upload flaw in Grav CMS, the content management software Cl0p used to run its own site, and used the access to claim Cl0p’s source code, its CMS plugins, its system logs, and the private cryptographic keys protecting Cl0p’s Tor hidden service address. The keys matter more than the defacement. As ShinyHunters put it, having Cl0p’s onion keys means it can run the same dark web address from its own infrastructure even if Cl0p regains its server, so if Cl0p kicks the group out, ShinyHunters claims, it would not matter at all.

The Demand Escalates by the Day

The initial demand, made on 19 September, was an eight-figure sum, which ShinyHunters described as 2.333% of its own claimed net worth. By 21 September the group had raised the price to everything Cl0p made from its 2025 Oracle E-Business Suite data theft campaign, plus more, and with interest, adding a demand for a public apology and a clause that the total rises every 24 hours Cl0p stays silent. Cl0p’s own response, once it regained partial control of the site, was to remove the defacement and claim ShinyHunters’ contact email did not work, an avoidance move rather than a denial.

Why This Should Worry Organisations That Paid Cl0p, Not Just Cl0p

ShinyHunters has also threatened to publish the identities of every company that paid Cl0p a ransom, the amounts involved and the Bitcoin addresses used to pay it, tied directly to Cl0p’s Oracle EBS campaign. That threat has nothing to do with any organisation’s own security posture today. It depends entirely on whether a rival criminal group decides to make good on an extortion demand against a competitor, a decision an affected company has no way to influence and no visibility into. Any organisation that treated a Cl0p ransom payment as a closed incident, in exchange for a deletion promise from a criminal group, is discovering that a criminal’s word was never the same thing as a resolved risk.

The Real Governance Lesson Here

None of this is confirmed by Cl0p or by a neutral party. Every figure above comes from ShinyHunters’ own claims, corroborated across multiple independent outlets but not yet verified by Cl0p or a third party. That uncertainty is itself worth carrying into the next risk review. An incident an organisation paid to make disappear can resurface years later, at a time and in a form it does not control, because the decision to disclose sat with a criminal the whole time, not with the organisation that paid. The practical question for this quarter is not whether an organisation is a past Cl0p victim. It is whether legal and the incident response lead have already agreed what happens the day a rival gang publishes that answer for them.

Two documents delivered in 2026 that both claim to tell a board how to govern cyber risk. One is a handbook. The other is law. The distance between the two is where most PMOs currently sit, translating voluntary best practice into something a director can actually be held to.

The Handbook: Comprehensive, Voluntary, US-Focused

In April 2026, the National Association of Corporate Directors and the Internet Security Alliance released the fifth edition of the Director’s Handbook on Cyber-Risk Oversight. It is thorough. Six principles cover treating cyber security as a strategic risk, monitoring legal and disclosure exposure, building board oversight structures, adopting an enterprise risk framework, guiding measurement and reporting, and encouraging systemic resilience. It cites more than 600 million tracked cyberattacks a day and projected annual cybercrime losses approaching 20 trillion dollars globally. What it does not do, because it is guidance rather than statute, is compel a single board anywhere to act on any of it.

The Law: Narrower, Binding, and Personal

Singapore closed that gap for its own critical infrastructure operators in 2026 with an updated Cybersecurity Code of Practice. Boards of operators across eleven sectors, energy, telecommunications, water, healthcare, banking, aviation, maritime, government and more, must now maintain a documented resilience framework covering risk tolerance, mitigation, transfer and recovery, reviewed at least annually. Certification deadlines follow in December 2026 and December 2027. Directors can face personal liability where a company fails to prevent or properly respond to an incident because of a lack of the skill, care or diligence the role required. That is a materially different proposition from reading a handbook. It converts board oversight from a best-practice expectation into a standard a director can be judged against.

The Gap Between Them Is Where PMOs Live

Most organisations operating internationally will encounter both models at once, comprehensive American guidance describing what good oversight looks like, and a narrower but binding Asian regulatory standard describing what oversight is legally required to look like. Neither one, on its own, tells a PMO what to actually build. The handbook is too broad to implement directly. The code is too sector-specific to generalise from. The practical work, translating six abstract principles into a working reporting cadence, a named accountable owner, and evidence a board can point to if asked, sits squarely inside the PMO’s remit rather than the CISO’s alone or the board’s alone.

What a PMO Should Build From Both

A credible cyber governance structure borrows the handbook’s breadth and the code’s specificity. That means a documented framework reviewed at a fixed interval, not an annual slide nobody revisits, a named board-level owner who can answer for the organisation’s posture in plain language, and evidence, tested and dated, that oversight was real rather than assumed. Boards do not need another handbook to read. They need proof that what the last one said actually happened.

By August 2026, four European countries, Poland, the UK, France and Germany, had entered the critical tier of a healthcare cyber risk index covering 30 nations. France was still rebuilding more than 1,000 workstations and roughly 200 applications, five months after an October 2025 attack hit eight sites. Germany’s Unimed incident had disrupted care for more than 135,000 people across connected institutions. Every one of these countries has invested heavily in hospital cyber security. None of that investment, on its own, has been enough.

The Diagnosis Is Cultural, Not Technical

Research published by King’s College London in March 2026 offers a specific explanation for why. Reviewing NHS Trust cyber resilience, the researchers concluded that ransomware remains the most acute threat facing hospitals not primarily because of a technology gap, but because of inconsistent governance maturity and, more pointedly, a cultural rather than technical or financial constraint. Trusts with comparable budgets and comparable tooling still show wildly different resilience outcomes, which points toward leadership and accountability structures as the actual variable rather than the size of the security budget.

A Framework Built Around Ownership, Not Just Controls

The KCL research proposes what it calls a Cyber Leadership Framework, built on board-level ownership of cyber risk, an empowered CIO or CISO with real authority rather than a title, and a deliberate effort to connect technical controls to what actually happens in a ward or a clinic rather than treating cyber security as a parallel IT concern. Its most structurally significant recommendation is greater centralisation of core cyber capabilities and shared services across otherwise fragmented Trusts, replacing dozens of individually under-resourced security functions with fewer, better-resourced shared ones.

The Same Fragmentation Problem Shows Up Across Borders

That fragmentation is not a uniquely British problem. The Black Book Europe-30 Healthcare Cyber Risk Pressure Index, measuring attack pressure, clinical digital dependence, supplier concentration and recovery friction across 30 countries, found 13 of them sitting in the two highest risk bands, with Poland, the UK, France and Germany specifically flagged as critical. Each of these health systems is organised differently, some more centralised than the NHS, some more fragmented, and all four still ended up in the same risk category. Centralisation on its own is not a guaranteed fix. What the KCL research adds is the missing piece, shared capability paired with genuine board-level accountability, rather than shared capability alone.

What This Means for Healthcare Programme Governance

A healthcare PMO reviewing cyber resilience investment should treat the KCL framework as a diagnostic tool rather than an NHS-specific recommendation. The practical test is straightforward: can a board member currently name who owns cyber risk for their organisation, describe what shared capability actually exists beyond their own site, and point to when that capability was last tested under real pressure rather than reviewed on paper. France’s five-month rebuild and Germany’s 135,000-person incident both suggest that answering those questions honestly, before an attack rather than after one, is the entire point of the exercise.