It is that.

But it is also something more difficult: a reminder that freedom can be declared before it is delivered.

That distinction matters. A proclamation is not the same thing as lived reality. A law is not the same thing as enforcement. A principle is not the same thing as protection. Between the announcement and the human being stands the system: the messenger, the court, the sheriff, the army, the town, the bus driver, the badge, the newspaper, the microphone, the memory.

And sometimes the system arrives late.

Sometimes it refuses to arrive at all.

That is why I have been thinking about Isaac Woodard.

Woodard was a Black World War II veteran. He served his country, came home in uniform, and was beaten and permanently blinded by police in South Carolina in 1946. He had survived war abroad and returned to a country still willing to deny him the basic dignity of citizenship at home.

That sentence should not become easy to read.

It should remain heavy.

Orson Welles understood that.

When Welles heard about Woodard’s beating, he used his radio program not merely to comment, but to witness. There is a difference. Commentary explains. Witness refuses to let the fact disappear.

Welles did not hide behind balance where balance would have been cowardice. He did not soften the matter into respectable distance. He spoke directly, morally, and publicly. He took a local atrocity and made it harder for the country to bury it.

The Radio Diaries series, Orson Welles and the Blind Soldier, tells this story with the care it deserves. It is the piece I would point people to first.

Welles’s words still cut through the years.

“The blind soldier fought for me.”

“I have eyes. He hasn’t.”

“Officer X, I’m talking to you.”

“Wash your hands, Officer X.”

There is no mistaking the purpose of that voice. It is not ornamental. It is not theatrical in the empty sense. It is theatrical in the ancient sense: a voice raised before the public so that the public must decide what sort of people they mean to be.

That is the part that stays with me.

Welles had a microphone. Woodard had been robbed of his sight. So Welles used what he had.

That is not a small thing.

A society often reveals itself by what it allows to remain local. Local silence is one of the oldest hiding places for national shame. A man is beaten. A town looks away. An officer is unnamed. A file is mishandled. A story becomes rumor. Time passes. Respectable people move on.

Welles refused to move on.

This is why Woodard belongs in a Juneteenth reflection.

Juneteenth is not only about the end of slavery finally being announced in Texas. It is about the distance between national promise and human delivery. It is about the terrible fact that freedom can be real in one document and absent in one life. It is about the machinery required to make a principle true.

Isaac Woodard’s story comes later, after emancipation, after Reconstruction, after service in uniform, after a war fought against fascism. And still the question remained: would the country’s declared principles reach the man standing at the bus stop, the jailhouse, the courtroom, the hospital bed?

In Woodard’s case, the answer was no.

That is why memory matters.

Memory is not nostalgia. It is not decoration. It is not a wreath placed politely on history so that everyone may return to lunch undisturbed. Memory is a form of accountability. It is how the present admits that the past is not finished merely because it is past.

I first encountered part of that idea not as abstraction, but on a wall.

When I worked at the Jewish Community Center of San Francisco, one of the values on the wall was Tzedek - Justice. Beneath it was a line from Emma Lazarus:

Until we are all free, we are none of us free.

That sentence has stayed with me.

It belongs in this reflection because it refuses the cheap version of freedom, the version that treats liberty as a private possession rather than a shared condition. It says freedom is not complete while another person remains excluded from its protection. It says justice is not a decorative virtue. It is a public obligation.

That is the spirit I hear in Juneteenth.

It is also the spirit I hear in Welles’s broadcasts about Isaac Woodard.

Woodard’s blinding was not only an attack on one man. It was an attack on the meaning of citizenship itself. If a decorated veteran could return from war, still in the shadow of his service, and be beaten blind by the machinery of local authority, then the country had not merely failed him. It had exposed the distance between its language and its delivery.

Until we are all free, we are none of us free.

That is not sentiment. It is systems thinking with a moral spine.

I also love that Welles’s voice traveled forward.

Logic sampled Welles’s commentary on No Pressure, including in “Obediently Yours.” That matters to me. Not because a sample fixes history. It does not. But because it proves that witness can move. A radio voice from 1946 can find its way into hip-hop decades later, and someone who never went looking for Isaac Woodard may suddenly hear Welles speaking across time.

That is how memory survives. Not always through monuments. Sometimes through archives. Sometimes through a podcast. Sometimes through a record. Sometimes through a voice that refuses, even now, to become quiet.

There is a lesson here for institutions, too.

Freedom is not self-executing.

Neither is citizenship. Neither is justice. Neither is equality before the law.

A country may declare its principles in magnificent language and still fail to build systems worthy of them. The gap between the two is where people are harmed. It is where Isaac Woodard was harmed. It is where countless others were harmed. It is where the flattering story a nation tells about itself meets the lived experience of those forced to test whether the story is true.

Juneteenth asks us to remember delayed freedom.

Isaac Woodard asks us to remember denied citizenship.

Orson Welles asks us to remember the duty of witness.

Emma Lazarus asks us to remember that freedom is not complete while others remain excluded from its protection.

And Logic, in his own way, reminds us that witness can travel farther than the moment that first required it.

So this Juneteenth, I am thinking less about celebration as a finish line and more about delivery as a moral obligation.

Freedom announced is not enough.

Freedom must arrive.

And when it does not, someone has to say so clearly enough that the silence cannot survive.

Sources and Listening

• Radio Diaries — Orson Welles and the Blind Soldier A three-part series on Isaac Woodard, Orson Welles’s radio campaign, and the case’s role in the broader civil rights struggle.

• Indiana University — Orson Welles on the Air, 1938–1946: Orson Welles Commentaries Indiana University’s archive entry for the July 28, 1946 episode in which Welles speaks about Isaac Woodard, Jr., who was beaten by police in South Carolina and blinded as a result.

• Internet Archive — 1946 Orson Welles Commentaries A downloadable collection of Welles’s 1946 commentaries, including broadcasts related to Isaac Woodard, the NAACP, and postwar civil rights.

• JCCSF — About Background on the Jewish Community Center of San Francisco and its Sheva Middot, including Tzedek - Justice and the Emma Lazarus line, “Until we are all free, we are none of us free.”

• Logic — No Pressure Credits Official album credits noting the use of excerpts from “Orson Welles Commentary (Born To Be Free)” performed by Orson Welles.

• Wellesnet — Logic samples Orson Welles on “Obediently Yours” Background on Logic’s use of Welles commentary on No Pressure, including the connection to Welles’s anti-racist broadcasts and the Isaac Woodard case.

Canonical, the company behind Ubuntu, recently acknowledged that its web infrastructure was under what it called a “sustained, cross-border attack.” Reports described the event as a Distributed Denial of Service attack affecting Ubuntu and Canonical services, with a group known as 313 Team, also called the Islamic Cyber Resistance in Iraq, claiming responsibility. As with most things involving attribution, Telegram channels, packet floods, and people with dramatic names, that claim should be handled with care. Claiming responsibility is not the same thing as proving responsibility.

Still, the incident matters.

It matters because Ubuntu is not some obscure hobby project hiding in the back room of computing history. Ubuntu is a major Linux distribution used by developers, enterprises, cloud providers, hobbyists, schools, labs, and people like me who want their machines to work without first negotiating with the spirits of seventeen forgotten dependencies.

I have used Ubuntu for years. I understand the appeal. It is practical, well-documented, widely supported, and familiar enough that most problems have already been suffered by someone else in public, which is one of the quiet blessings of civilization.

But this incident made something visible.

Not because it proved Ubuntu is bad. It did not. Not because it proved Snap caused the outage. It did not. Not because it proved Canonical is malicious. It did not.

It made visible the assumptions underneath the system.

The Marine Corps has a saying about assumptions that is not fit for a corporate slide deck, which is one reason it is useful. The polite version is this: assumptions are where plans go to die.

That is what this incident exposed for me. What had I assumed about Ubuntu’s resilience? What had I assumed about centralized stores? What had I assumed about open source infrastructure simply because the source code was open?

The answer, uncomfortably, is that I had assumed more than I had inspected.

“Cross-Border Attack” and the Language of Seriousness

Canonical’s initial public language described the event as a “sustained, cross-border attack.” Later reporting quoted Canonical confirming a sustained, cross-border DDoS attack.

That phrase is not necessarily false. A DDoS is often cross-border in the practical sense. Compromised machines, botnets, proxies, rented infrastructure, and hostile traffic do not pause politely at customs checkpoints. Packets are famously indifferent to passports.

But “cross-border attack” is one of those phrases that sounds more clarifying than it is. It gestures toward seriousness without giving users much operational clarity.

What users needed was not a geopolitical adjective. They needed plain information: What services are affected? Are package repositories affected? Are ISO images safe? Are security advisories reachable? Are Snap services degraded? Are APT mirrors functioning? What should administrators do if normal update paths fail?

To Canonical’s credit, it later stated that mitigations had been implemented and services affected by the DDoS attack had been restored, though some services might remain partially degraded. That is useful. But the earlier phrase still matters because crisis communication is part of infrastructure trust.

In an incident, clarity is not decoration. It is a control.

A good incident statement does not need to satisfy everyone’s curiosity. It does need to tell users what is known, what is not known, what is affected, what is not affected, and what they should do next. Otherwise, people fill the gaps themselves. The internet, being a generous institution, will fill them with panic, speculation, memes, and four men in a forum explaining why this would not have happened on Gentoo.

Availability Is Security

It is tempting to think of DDoS attacks as crude. In many ways, they are. A DDoS is not a subtle jewel thief descending through a skylight. It is more like a mob blocking every road into town while shouting.

But crude does not mean harmless.

Availability is part of security. That is especially true when the affected infrastructure supports operating system downloads, authentication, developer services, package access, security guidance, or update workflows.

If users cannot reliably reach the services they need during a security event, the system is weaker than its design documents suggest. If administrators cannot easily find guidance, confirm integrity, or route around failure, then the outage becomes more than inconvenience. It becomes friction at precisely the moment friction is most expensive.

That is why this was more than a bad day for a website.

It was a stress test.

And systems reveal themselves under stress.

The Copy Fail Timing Problem

There is another wrinkle in the story, and it is precisely the sort of wrinkle that makes infrastructure people age in dog years.

Around the same time Canonical was dealing with the DDoS, the Linux ecosystem was also responding to Copy Fail, CVE-2026-31431, a high-severity local privilege escalation vulnerability in the Linux kernel. Canonical described it as affecting Ubuntu releases before 26.04, with mitigations released through kmod and kernel fixes following through normal update channels.

Some people speculated that the DDoS could be related to Copy Fail. Tom’s Hardware noted that speculation, while also calling the premise “a little shaky.” That caution is warranted.

This does not prove Copy Fail caused the DDoS. It does not prove the attackers were trying to prevent patching. It does not prove Ubuntu packages were compromised. It does not prove that anyone should run screaming into the woods holding a Debian netinst ISO like a sacred object.

Those would be dramatic claims, and dramatic claims are best handled with tongs.

But the timing matters anyway.

Copy Fail is not remotely exploitable by itself. An attacker needs some sort of local foothold first: an account, a workload, a CI job, a container context, or another way to execute code on the system. Once that foothold exists, however, the vulnerability becomes a path to root. In plain English, it can turn a bad day into a much worse one.

That makes availability part of the security story.

During a vulnerability response, users need clear advisories, reachable update infrastructure, working mirrors, automation that does not fail mysteriously, and communication that tells them what is affected and what is not. If the front door is being pelted with packets while the building is also trying to distribute fire extinguishers, the fire extinguishers may still exist. That is good. But one is entitled to ask why everyone was expected to find them through a doorway currently occupied by vandals.

The DDoS did not need to be about Copy Fail for Copy Fail to matter.

The Mirrors Held

This is where the APT mirror network deserves credit.

The detail that keeps tugging at me is not only what failed. It is what did not.

During the packet storm, the older APT mirror model appears to have done what distributed infrastructure is supposed to do. Not perfectly, not romantically, and certainly not with the sort of glossy product language that makes executives feel they have purchased the future in convenient quarterly installments. But it held well enough to remind us why distributed systems exist.

APT mirrors are not magic. They are ordinary infrastructure, maintained by people, universities, providers, institutions, and mirror operators who accept the unglamorous responsibility of keeping packages available. Ubuntu’s own documentation describes archive mirrors, release mirrors, country mirrors, Launchpad registration, sync requirements, and regular update expectations. Archive mirrors are expected to update every six hours. Release mirrors update every four hours or use push mirroring.

This is not glamorous architecture.

It is better than glamorous.

It is legible. It is boring. It is distributed. It is the sort of thing that survives trouble precisely because no single door has to remain open for the whole town to eat.

There is a quiet genius in boring infrastructure. Mirrors, sync jobs, package indexes, signatures, fallback hosts, and the ability to change sources are not the stuff of keynote demos. They are not sleek. They are not especially charismatic. But when the weather turns hostile, charisma is a poor substitute for redundancy.

The old mirrors behaved like infrastructure.

That matters.

The Store Becomes the Chokepoint

This is where Snap comes back into the conversation.

The criticism of Snap has often been treated as ordinary Linux tribalism, and to be fair, Linux tribalism is one of the world’s most renewable energy sources. But beneath the shouting there has always been a serious architecture question.

A software distribution model is not only a packaging choice. It is a trust model. It is an availability model. It is a governance model.

Who controls the store? Who reviews submissions? Who decides what is verified? Who operates the infrastructure? What happens when that infrastructure is unavailable? What alternatives exist for users, enterprises, or distributions that do not want their operating model tied so tightly to one company’s services?

Snapcraft’s own documentation describes the official Snap Store as hosted and curated by Canonical. That may be perfectly sensible for many use cases. Centralization can bring benefits: consistency, review processes, publisher identity, simplified distribution, automatic updates, and a more controlled user experience.

But convenience has a habit of putting on a nicer jacket and returning as dependency.

That is the uncomfortable comparison with APT mirrors.

APT’s older model assumes alternate paths. Snap’s public-store model assumes a central service. Those are different philosophies, not just different technologies.

The DDoS did not create that difference. It merely removed some of the polite fog around it.

Open Source Is Not Automatically Resilient

One of the lazier arguments in technology is that open source is automatically resilient because the code is open.

I like open source. I prefer it whenever practical. I think it is one of the great achievements of modern technical culture. It gives users, developers, researchers, and institutions an ability to inspect, modify, preserve, and improve software in ways closed ecosystems often resist.

But openness of source code is not the same thing as resilience of the operating model.

A system can be open and still centralized. It can be transparent in one layer and opaque in another. It can publish code while concentrating distribution through a small number of chokepoints. It can call itself community-oriented while quietly making the community dependent on infrastructure it does not control.

The question is not only, “Can I read the code?”

The question is also: Can I get the software? Can I verify it? Can I update it? Can I route around failure? Can I mirror what matters? Can the system degrade gracefully when the world becomes impolite?

Because the world will become impolite. It has a schedule.

Open Source in a Political World

There is another piece here, and it is easy to miss if one thinks of Linux distributions as mere technical artifacts.

Open source does not live in a monastery.

It lives in the world. And the world contains botnets, proxies, criminal markets, state-aligned actors, hacktivists, bored teenagers, grievance politics, sanctions, wars, extortion attempts, and people who believe civilization is best improved by sending junk traffic at package infrastructure.

Ubuntu, Debian, Fedora, Arch, Alpine, Red Hat, SUSE, and the rest are not just operating systems in the abstract. They are parts of the modern technical commons. They support cloud workloads, developer machines, CI/CD systems, laboratories, classrooms, factories, home servers, small businesses, and governments. They are infrastructure in the broad civic sense.

That means they are now part of the geopolitical weather.

A DDoS against Canonical is not just a nuisance. It is a reminder that open-source infrastructure is also strategic infrastructure, and strategic infrastructure attracts strategic stupidity.

Sometimes the stupidity wears a uniform. Sometimes it wears an ideology. Sometimes it wears a Discord handle and sells DDoS-as-a-service to people whose moral development peaked somewhere between “found a booter panel” and “learned to spell operational security incorrectly.”

But the effect is the same. Systems we rely on are placed under pressure, and their hidden assumptions become visible.

Why This Pushes Me Toward Fedora or Debian

This incident pushes me, at least emotionally, a little farther from Ubuntu and a little closer to Fedora or Debian.

Not because Fedora or Debian are magic kingdoms where packets arrive on horseback bearing constitutional rights. They have their own tradeoffs, politics, rough edges, governance disputes, maintenance burdens, and software choices capable of ruining a Saturday.

But they feel different in the areas that now matter more to me.

Debian appeals to the part of me that wants infrastructure to be boring in the way a good bridge is boring. It is conservative, widely mirrored, deeply rooted in the free software tradition, and less inclined to make the user feel gradually enrolled into a corporate product strategy.

Fedora appeals to the part of me that wants modern Linux, strong engineering, upstream alignment, and a desktop experience that does not revolve around Canonical’s preferred packaging future. Fedora is not neutral ground. It has Red Hat’s shadow over it, and anyone pretending otherwise is selling something. But the tradeoffs feel different.

Ubuntu still has strengths. It remains useful. It remains familiar. It remains one of the easiest distributions to recommend to many people. I am not throwing it into the sea.

But trust is not only built by being useful.

Trust is built by making the user comfortable with the tradeoffs.

And this incident made me less comfortable.

The Infrastructure We Forgot to Question

The lesson here is not that Ubuntu is doomed, or that Snap is evil, or that everyone should reinstall their laptops before dinner.

The lesson is simpler and more durable: open-source resilience is not guaranteed by open code alone. It depends on the design of the whole system around the code.

It depends on distribution. It depends on governance. It depends on mirrors. It depends on update paths. It depends on incident communication. It depends on whether users and administrators have alternate routes when the main road is blocked by a political parade of garbage packets.

A system can be open and still centralized. It can be convenient and still brittle. It can be widely trusted and still depend on infrastructure whose failure reveals assumptions nobody wanted to inspect too closely.

That is the part worth taking seriously.

Canonical’s DDoS did not prove that Ubuntu is broken. It did not prove that Snap is the end of civilization, though I recognize that some corners of the Linux internet will continue their liturgical dance on that subject with or without evidence.

What it did prove is more useful.

It proved that architecture has a memory. The older APT mirror model remembered a world where distribution needed redundancy. The newer centralized services remembered a world where convenience, identity, review, and control could be concentrated in a store.

Both worlds have lessons.

But when the weather turned political, the old mirrors looked wiser than they had the day before.

And that is enough to make a man reconsider his assumptions.

Sources

The first is by misfortune. A market turns, a technology shifts, a rival gets there first, and the splendid machine discovers that history has no respect for strategic plans.

The second is more humiliating. It is to receive warning, possess intelligence, hold meetings, circulate memos, nod gravely, and then continue on as though knowledge itself were a form of action. This second method is especially popular among large organizations, partly because it feels responsible right up to the moment it becomes fatal.

Nortel remains interesting because it appears to have suffered from both.

For a time, Nortel was not merely successful. It was the sort of company a nation points to when it wants proof that its future has arrived. It had scale, laboratories, engineers, patents, fiber optics, ambition, and the confident air of an institution that had begun to suspect the future might arrive wearing its logo. It was, in other words, exactly the sort of enterprise one imagines would know how to protect what it had built.

This is where the story acquires its sting.

The familiar account of Nortel’s fall includes the usual cast of modern corporate tragedy: the telecom bubble, acquisitions, strategic overreach, accounting scandal, job cuts, deteriorating confidence, and the long dreary procession by which an institution discovers that market capitalization is not the same thing as immortality. All of that matters. One should be suspicious of any story that explains a collapse of that scale with a single villain and a dramatic soundtrack.

But there is another thread in the Nortel story that lingers in the mind because it is so painfully modern. Warnings reportedly surfaced about intrusions into executive accounts and access to sensitive internal material. The important fact is not merely that someone may have been in the walls. The important fact is what happened after that became known.

Or rather, what did not.

That is the part worth dwelling on, because it reveals something larger than a breach. It reveals the difference between information and consequence.

Modern organizations are astonishingly good at gathering signals. They monitor, detect, classify, flag, escalate, review, and distribute. They produce dashboards with little colors on them, which is always comforting. They generate alerts with the crisp procedural dignity of a ship’s bell in a well-run disaster. They are, in many cases, rich in information. What they are not always rich in is the willingness to let that information disrupt hierarchy, convenience, optimism, or quarterly rhythm.

And so the signal arrives, and instead of becoming action, it enters the digestive tract of the institution.

There it is processed. It is discussed, contextualized, translated into language suitable for people who dislike hearing from specialists, and finally rendered into something so balanced, so mature, and so operationally respectful that whatever urgency it once possessed has been carefully removed for everyone’s comfort. By the end of this process, what began as danger has become governance, and governance, alas, is often the method by which danger is taught to sit quietly in the corner until it grows teeth.

This is not only a cybersecurity problem. It is an organizational problem. It appears in quality systems, in compliance functions, in safety programs, in vendor oversight, in military planning, in public administration, and in every other arena where human beings confuse the existence of a process with the existence of a capability.

A real capability changes events.

That is the test.

A control is not real because it exists in a binder, or a slide deck, or a beautifully formatted policy document written in the sorrowful dialect of corporate reassurance. A control is real if it changes behavior, assigns ownership, creates thresholds, triggers decisions, and produces action before the matter graduates into catastrophe.

Otherwise, it is not a control. It is a decorative belief.

Institutions are full of decorative beliefs. They believe that because a risk has been identified, it has been addressed. They believe that because a responsibility has been written down, it has an owner. They believe that because everyone in the room agrees something is important, somebody else will deal with it. They believe that awareness is adjacent to action, that reporting is adjacent to remedy, that seriousness of tone is adjacent to seriousness of response. These are charming beliefs. They are also how very intelligent organizations end up holding autopsies for futures they once assumed were secure.

This, to me, is the enduring lesson in Nortel.

The company did not become a cautionary tale simply because risk existed. Risk is the admission price for doing anything worthwhile. Nor did it become a cautionary tale merely because hostile actors may have found their way into places they did not belong. In a world of states, spies, rivals, and opportunists, that is not shocking. What remains shocking, because it remains common, is the possibility that an institution can know something serious and still lack the internal machinery required to make that knowledge operationally decisive.

That is a systems failure.

It is also a human one.

Large organizations do not generally fail for lack of intelligence. They fail because intelligence collides with vanity, inconvenience, diffusion of responsibility, and the ancient managerial hope that a problem noticed today might somehow become a lesser problem tomorrow if everyone behaves calmly enough around it. Human beings are brilliant at this sort of evasion. We can convert warning into process, process into language, language into delay, and delay into an atmosphere of mature prudence. It is one of our more polished skills.

Unfortunately, the world does not always reward polish.

There is a certain kind of executive mind that treats security, quality, governance, and operational discipline as supporting functions, regrettably necessary but faintly separate from the real business of strategy. This is a mistake. In a serious institution, those things are strategy. The protection of critical knowledge is strategy. The ability to act on credible warning is strategy. The existence of clear decision rights before a crisis, rather than improvised authority during one, is strategy. An organization that cannot convert knowledge into action does not have an information problem. It has a command problem.

That distinction matters.

We like to flatter ourselves that collapse arrives with trumpets. Usually it arrives administratively. It is minuted, deferred, reviewed next quarter, and assigned to a workstream. By the time it becomes dramatic, the important opportunities have already been missed in rooms full of competent people saying reasonable things.

Which brings us back to Nortel.

The final lesson is not that innovation failed. Nortel had innovation. Nor is it that talent failed. It had talent in abundance. The darker possibility is that talent and innovation existed inside an institution whose operating system was not equal to the risks attached to its own importance. It may have known more than it could effectively act upon. That is a dangerous condition for any organization, and a terminal one for an organization whose value lies in what it knows.

There is something almost classical about that. Tragedy, after all, is not ignorance meeting fate. More often it is knowledge meeting character.

The warning was there, or near enough. The larger question was whether the institution had built a structure capable of hearing bad news in time to do something expensive, disruptive, and necessary about it. That is the sort of question every modern organization ought to ask itself, preferably before the answer is supplied by events.

Because the great danger is not always the threat you failed to imagine.

Sometimes it is the threat you recognized, discussed, documented, and politely declined to operationalize until the bill arrived.

That, in the end, is the more unnerving story. Not that the storm existed, but that the ship may have received reports about the weather and chosen, with all due professionalism, to continue arranging the deck furniture.

Authorities in the United States, Canada, and Germany disrupted infrastructure tied to four botnets called Aisuru, Kimwolf, JackSkid, and Mossad. The official story says those botnets compromised more than three million connected devices and were used to drive DDoS attacks of extraordinary scale.

That sounds like a cyber story. It is not. Not really.

It is a governance story.

No sorcery was required. No death ray from Mars. The machinery was already here, plugged in, trusted, and humming along in offices, homes, field sites, and closets no one has opened in months. Routers. Cameras. Boxes with blinking lights. Cheap, connected, and forgotten. The attackers did not invent an army. They conscripted one.

That is the part worth your attention.

What matters here

The interesting question is not how many devices were taken over. The interesting question is how many devices in your own environment could be.

1. Do you know which devices can become someone else’s infrastructure?

Most organizations think in categories that make them comfortable. Servers matter. Laptops matter. The little appliance in the corner does not matter until it does.

But if a device is connected, reachable, weakly managed, and rarely patched, then it is not a harmless convenience. It is a latent liability. It may sit quietly for months, doing its small assigned duty, until someone else decides it has a more interesting purpose.

A machine with no owner is still owned. Just not by you.

2. Are IoT and edge devices governed like real production assets?

There is a common superstition in operations: if something is small, cheap, or boring, it must also be low-risk. That is nonsense.

A camera does not become safe because it is boring. A router does not become harmless because nobody talks about it in steering committee meetings. An Android box does not become trustworthy because Finance never heard of it.

If the device is connected, it needs the same old unglamorous disciplines that keep everything else from becoming a fire: ownership, lifecycle control, patching, visibility, retirement. If those are absent, then you are not running a system. You are running a wish.

Luck is not a control.

3. Can you tell when “small devices” start behaving like attack infrastructure?

The official account says these botnets launched hundreds of thousands of attacks and caused real financial harm. That means the signal was there. The question is whether anyone who was responsible could see it in time, and whether they knew what they were looking at when they did.

For most teams, that comes down to a few unromantic questions:

• Can you see internet-exposed devices clearly?
• Do you know what normal outbound behavior looks like?
• Will anyone notice when one of these things starts speaking in a foreign tongue at machine speed?
• Is there a named human being who owns the problem when that happens?

Most failures of this kind are not failures of intelligence. They are failures of housekeeping.

4. Is DDoS resilience treated as a business-continuity issue?

Another common mistake is to hand DDoS off to the network team and call it a day, as though a flood of malicious traffic were only a technical inconvenience.

It is not. It is a continuity problem.

When systems are overwhelmed, the real questions are not abstract:

• Which services must remain reachable?
• Which dependencies break first?
• What can be degraded safely?
• Who talks to customers, partners, and internal teams when normal channels are under strain?

At sufficient scale, DDoS stops being a nuisance and starts becoming a test of whether leadership understands its own business.

The practical takeaway

The recent disruption of these botnets is good news. It is also temporary news.

The underlying condition remains the same: the world is full of insecure, weakly governed connected devices, and adversaries have shown again and again that they are happy to put them to work.

So the useful question is not whether the government disrupted this batch.

The useful question is this:

Which connected devices in your environment are important enough to inventory, patch, monitor, and retire deliberately, and which ones are still running on neglect and optimism?

If the answer is vague, then the danger is not hypothetical. It is merely waiting its turn.

A few useful checks

• Identify every internet-facing and remotely manageable IoT or edge device
• Assign a real owner to each device class
• Confirm patch responsibility and firmware hygiene
• Remove default credentials and weak remote access paths
• Baseline outbound behavior for non-traditional devices
• Alert on unusual traffic, scanning, or command patterns
• Tie DDoS response to business priorities, not just technical procedures
• Hold third-party and field-deployed devices to the same standards as internal ones

The larger point is simple enough for a child, which is one reason adults tend to miss it:

A device fleet becomes a security problem long before it becomes a headline.

Public reporting indicates the incident disrupted Stryker’s Microsoft environment and may have involved remote wiping of managed Windows devices after attackers gained privileged access. Even without a classic ransomware pattern, the operational impact was severe.

That is the part leaders should pay attention to.

If an attacker can abuse identity, endpoint management, or administrative tooling, the blast radius can be just as serious as a traditional malware event. The lesson is not only cyber. It is governance, operations, and continuity.

What matters here

A few practical questions matter more than the headlines:

1. Is device management treated like a critical control plane?

If an attacker gained privileged access to your identity and endpoint-management stack, could they push destructive actions across the fleet?

If the answer is unclear, that is already a problem.

2. Are destructive actions tightly governed?

Remote wipe, reset, unenroll, and policy enforcement all have legitimate uses.

The question is whether those capabilities are protected by:

• strong approval paths
• segmentation
• break-glass controls
• alerting for unusual use

A capability that is safe in normal operations can still become an enterprise-wide risk if privilege and oversight fail at the same time.

3. Can the organization detect mass destructive actions fast enough?

A mature environment should be able to detect unusual wipe, reset, unenroll, or large-scale policy events quickly.

It should also be clear:

• who gets alerted
• who can respond
• how the action gets interrupted
• how the organization verifies whether the event is legitimate or malicious

4. Does continuity planning assume simultaneous loss of endpoints and collaboration systems?

Many organizations plan for an application outage or a site outage.

Fewer plan for a scenario where:

• managed endpoints are disrupted
• internal communications are degraded
• administrative access is limited
• teams cannot coordinate normally

That gap matters.

The practical takeaway

Endpoint management, identity, and administrative privilege are operational-risk issues, not just technical issues.

A simple internal stress test is this:

Could an attacker with privileged access use your endpoint-management and identity systems to push destructive actions across your fleet before anyone stopped it?

If the answer is unclear, the next step is not more discussion. It is control review.

A few useful checks

• Identify which administrative systems can affect the largest number of endpoints at once
• Review what approvals are required for destructive or high-impact actions
• Confirm what alerts would fire if a mass wipe or reset were attempted
• Test how quickly the team could validate whether the event was malicious
• Review which business processes would fail first if endpoints and collaboration tools disappeared at the same time

The broader point is simple:

A control plane is still a control plane when an attacker is the one using it.

The Stryker situation is a useful case study because it shows what happens when a widely used vendor ecosystem experiences a broad disruption. The technical event is only half the story. The other half is operational: how teams adapt, what workarounds emerge, and whether organizations can stay safe and compliant while systems are degraded.

This post is written for a mixed audience: quality leaders operating in regulated environments and cybersecurity professionals who want to understand how a cyber event becomes a safety and governance event.

What happened (facts first)

Stryker reported a cybersecurity incident that led to a global disruption impacting its Microsoft environment, and said it was working to restore systems and operations.

The company also filed an SEC 8-K describing the incident and the operational impact from the disruption.

Separately, reporting described how downstream healthcare workflows were affected, including reliance on fallbacks when connectivity or integrations were unavailable.

Note: This post focuses on operational and governance lessons rather than attributing actors. Attribution can change as investigations evolve.

The point for both GxP and cyber teams

In regulated environments, “continuity” is not just uptime. It is the ability to keep decisions safe, traceable, and governed while operating in degraded mode.

When a system goes down and teams fall back to manual steps, three things tend to happen quickly:

1) Controls weaken (informal workarounds become the workflow)
2) Traceability degrades (decisions move to phone calls, chat, and memory)
3) Risk increases (detection and escalation paths become unclear)

That is why cyber resilience is a quality capability, not just a security capability.

What quality leaders should take seriously

1) Integrations are patient-safety dependencies

Most “patient-critical” workflows are not a single system. They are a chain: device, connectivity, identity, routing, receiving system, storage, and retrieval. When any link breaks, teams substitute human memory and manual communication.

Your continuity plan should be written at the workflow level, not the application level.

2) Degraded mode needs predefined controls

If you have no defined degraded mode, you will still operate. You will just operate without consistent controls.

A strong degraded-mode design answers:

• What is allowed to continue?
• What must stop?
• Who can authorize exceptions?
• What is the minimum documentation required?
• How do we reconcile back into the system later?

3) Cyber incidents can become data integrity incidents

Even when the initial impact looks like availability, degraded operations commonly create integrity issues:

• delayed entry and backdating risk
• incomplete audit trails
• conflicting “source of truth” across systems
• missing reconciliation evidence after restoration

Quality systems should anticipate this and include reconciliation steps as part of the incident playbook.

A practical checklist (24 to 72 hour survivability)

Use this as a fast self-assessment for any critical vendor platform or integration.

Workflow continuity

• Do we have a documented way to operate safely for 24 to 72 hours if the system is offline?
• Are the fallback steps role-based and trained, or tribal knowledge?

Ownership and escalation

• Is there a named owner for the workflow end-to-end (not just the application owner)?
• Are severity tiers and stop rules defined ahead of time?

Documentation and traceability

• Do we have a minimal degraded-mode record template (who, what, when, why, and risk decision)?
• Do we have a reconciliation plan that is auditable (what gets reconciled, how, and who signs off)?

Vendor and evidence expectations

• Do vendor contracts define incident notification timing and required details?
• Do we have access to the logs and evidence we would need to defend decisions later?

Testing and readiness

• Have we run a tabletop exercise on this workflow in the last 12 months?
• Have we tested the manual workaround, not just written it?

If you cannot answer these quickly, you likely have a survivability gap.

Why cyber teams should care about the GxP angle

In healthcare and life sciences, downtime is not just lost productivity. It can alter clinical decisions, change what information is available, and introduce integrity and documentation risks that persist after systems return.

Cyber response is stronger when it includes quality and operational leadership early, because those teams know:

• where the actual risk pathways are
• which workflows are safety-critical
• what evidence will be required later
• which controls must remain in place even during disruption

Events like this are a reminder to treat vendor platforms and integrations as controlled systems with defined boundaries, fallback modes, and auditable recovery.

If you want a lightweight, inspection-ready baseline for continuity planning that connects cyber response to quality controls, I can share a starter template you can adapt.

Contact: contact@kennethjbrandt.com

Sources

• KrebsOnSecurity: Iran-backed hackers claim wiper attack on medtech firm Stryker
  https://krebsonsecurity.com/2026/03/iran-backed-hackers-claim-wiper-attack-on-medtech-firm-stryker/

• Stryker: Message to customers (March 2026 update)
  https://www.stryker.com/us/en/about/news/2026/a-message-to-our-customers-03-2026.html

• U.S. SEC: Stryker 8-K filing (March 2026)
  https://www.sec.gov/Archives/edgar/data/310764/000119312526102460/d76279d8k.htm

• The Record (Recorded Future News): Stryker recovery timeline / incident reporting
  https://therecord.media/stryker-tells-sec-unknown-timeline-recovery

• TechCrunch: Stryker hack claim coverage
  https://techcrunch.com/2026/03/11/stryker-hack-pro-iran-hacktivist-group-handala-says-it-is-behind-attack/

Two patterns are worth paying attention to if you operate in regulated environments.

1) Distillation at industrial scale

Anthropic reported “distillation” campaigns where organizations created large volumes of Claude interactions through fraudulent accounts to extract model behavior for training.

In plain terms: if a model is accessible, someone will try to siphon capability at scale.

2) AI used to orchestrate cyber activity

Anthropic also published a report describing what it called the first reported AI-orchestrated cyber espionage campaign, and AP covered the same development.

Whether you are running clinical systems, manufacturing systems, or vendor platforms, cyber events can become quality events fast.

Why this matters for GxP teams

In GxP, your job is predictable outcomes under uncertainty. AI adds new uncertainty:

• Hidden workflow drift
• Untracked “configuration” changes (prompts, retrieval sources, thresholds)
• Weak provenance for data and decisions
• Vendor tools that behave like black boxes

The fix is not panic. It is control design.

The practical move: treat AI like a controlled system

If you want inspection-ready AI operations, start with five basics:

1) Define intended use. Write down what the AI is allowed to do and what it is not allowed to do. If it touches a GxP decision, define the boundary and escalation path.
2) Treat prompts and workflow logic as configuration. If people can quietly change prompts, retrieval sources, or thresholds, you have an untracked change. That is a control gap.
3) Make audit trails answer inspection questions. Not just what happened, but who approved it, what evidence supported it, and what monitoring confirms it still works.
4) Put vendors on the hook for evidence. If an AI feature is vendor-provided, insist on logging, retention, access control design, incident notification expectations, and rollback options.
5) Pre-write incident response. Retrain vs rollback vs suppress should never be improvised. Your corrective action must match the failure mode, and the rationale must tie back to risk.

A quick self-check (15 minutes)

• Do I know every place AI is used in the workflow today?
• Do I have an owner for each AI-enabled capability?
• Can I show what changed, when, and why?
• Can I roll back quickly if outputs regress?
• Do I have a simple monitoring pack with thresholds, actions, and review cadence?
• Do vendors provide logs and evidence I can defend?

If any of those are “no,” the fix is usually straightforward: scope, ownership, logging, change control, and response playbooks.

If you want a lightweight, inspection-ready baseline for AI governance in a GxP environment, I am happy to share a starter checklist.

Contact: contact@kennethjbrandt.com

Sources:

• Anthropic: Detecting and preventing distillation attacks
• Anthropic: Disrupting the first reported AI-orchestrated cyber espionage campaign (full report)
• AP: Anthropic warns of AI-driven hacking campaign linked to China

What good looks like

• Alert limit = investigate signal and document assessment
• Action limit = execute a defined response (change control,CAPA,rollback,process controls)

Starter checklist

1) Define the baseline (validated reference) 2) Pick acceptance metrics (what “acceptable” means) 3) Separate signals (data drift,concept drift,performance drift) 4) Set limits by risk (patient impact drives tightness+SLA) 5) Assign owner+backup (named accountability) 6) Define response SLAs (review,escalation,closure) 7) Document decisions (review minutes matter) 8) Link actions to change control (threshold updates,retraining,rollback)

Visual checklist

If you want an editable template version,reach out via the contact page.

Starter checklist

1) Define scope (systems and records that support GxP decisions) 2) Confirm event coverage (create,modify,delete,override,access) 3) Set review requirements (who reviews,how often,what triggers review) 4) Define retention (records+metadata+raw logs+reports) 5) Validate retrieval (can you produce it quickly,consistently,completely) 6) Ensure traceability (signal->review->decision->action) 7) Tie to SOPs (roles,escalation,investigation paths)

Visual checklist

A simple rule: if you can’t retrieve the audit trail record package quickly,you don’t have audit trails as a control. You have a hope.

Can you show quickly and consistently what you control, who owns it, and where the evidence lives?

This post lays out a practical approach that scales from development into commercial manufacturing.

The core idea (in one line)

CQA → CPP/CMA → control layers → owner/approvals → evidence

If you can’t trace your strategy end-to-end, it won’t scale—and it won’t hold up under scrutiny.

Step 1: Start with CQAs (what must be true for the patient)

CQAs are the outcomes you’re protecting: identity, strength, purity, sterility assurance, content uniformity, etc.

Practical rule: write each CQA in plain language:

• What does “good” look like?
• What would “bad” mean for patient impact?

If you can’t explain a CQA without acronyms, the map will turn into paperwork instead of control.

Step 2: Link CPPs/CMAs (what drives those CQAs)

CPPs and CMAs are the levers that meaningfully move CQAs.

Keep it honest:

• If it doesn’t move a CQA, it’s not a CPP/CMA—it’s noise.
• If it moves a CQA, it needs a control layer you can defend.

Step 3: Define control layers (controls exist in layers, not one test)

Most failures come from “single-point control thinking”:

“We test it at the end, so we’re fine.”

That doesn’t scale. Robust control strategies use layers, for example:

• Material controls (supplier qualification, incoming acceptance)
• Process controls (setpoints, alarms, in-process checks)
• Procedural controls (SOPs, training, line clearance)
• Analytical controls (IPC testing, release testing)
• System controls (access, audit trails, data integrity)

Goal: multiple independent ways to prevent/detect a bad outcome.

Step 4: Assign owners + approvals (RACI that isn’t theater)

A control strategy fails when ownership is ambiguous.

At minimum, capture:

• Owner: accountable for control performance & upkeep
• Approvers: who approves changes (QA, MSAT, Validation, etc.)
• Escalation path: who gets called when limits are breached

If an auditor asks “who owns this control?” your answer should be immediate.

Step 5: Link evidence (where it lives, how to retrieve it)

Controls don’t exist unless you can produce evidence.

For each control layer, link:

• The record type (batch record section, log, system report)
• The system of record (eQMS, MES, LIMS, historian, DCS, etc.)
• The retention expectation (as applicable)
• The retrieval path (who pulls it, how long it takes)

Fast test: can your team retrieve a representative record in under 10 minutes?

Step 6: Review cadence + triggers (change control is your friend)

A control strategy should be reviewed on purpose, not “when someone remembers.”

Use:

• Periodic review (quarterly/ annually depending on risk)
• Triggered review at change control events:
  • material/supplier change
  • parameter range change
  • equipment/software change
  • deviation trend/complaint trend
  • method change

This is how you keep the strategy aligned to the validated state.

Common failure modes (what breaks first)

In practice, traceability usually breaks at: 1) Handoffs (development → tech transfer → commercial) 2) Ownership gaps (everyone is involved, nobody is accountable) 3) Evidence sprawl (records scattered across systems) 4) “One test” thinking (weak layering) 5) Unmanaged change (strategy doesn’t update when reality changes)

A simple audit question to pre-answer

“Show me how this CQA is controlled, and prove the controls are working.”

If you can answer that with:

• the map
• named owners
• linked evidence
• review history

…you’re in a strong position.

Question for you

Where does your traceability usually break first, process controls, test strategy, or documentation handoffs?