When Your Emergency Alert System Becomes the Emergency: The CodeRED Ransomware Crisis

✅ The Crisis: Crisis24's CodeRED system, used by hundreds of US municipalities, was compromised by INC ransomware in November 2025, disrupting emergency notifications and exposing citizen data

✅ The Fallback Failure: Many jurisdictions discovered their backup communication plans were inadequate when their primary alert system went dark

✅ The Trust Break: Douglas County, Colorado publicly terminated its CodeRED contract, signaling how quickly platform trust can collapse after a breach

✅ The Real Lesson: If your crisis plan assumes your primary communication platform will work, you have a wish list, not a strategy

✅ The Action Required: Organizations must document, resource, and regularly test Plans B and C for crisis communication, not just Plan A

In early November 2025, the INC ransomware group struck Crisis24's infrastructure. The attack wasn't just a technology problem, it became a communication crisis about the ability to communicate itself.

CodeRED serves as the emergency notification backbone for hundreds of US towns and cities. Weather alerts. AMBER alerts. Evacuation warnings. All the messages that keep people safe in dangerous situations. On November 10, attackers encrypted files in the CodeRED environment, and suddenly that backbone snapped.

Some jurisdictions scrambled to social media. Others posted updates on municipal websites. A few resorted to something that seemed almost archaic: door-to-door notifications to warn residents of immediate threats.

Douglas County, Colorado made a different choice entirely. They publicly severed ties with Crisis24 and announced they would find an alternative platform. The message was clear, trust, once broken, doesn't always rebuild.

The CodeRED incident demonstrates how a single-point failure cascades into multiple communication emergencies simultaneously.

Core alerting capability vanished. The very system designed to protect people during life-safety emergencies became unavailable precisely when it was needed most. After the ransomware actors encrypted files in the CodeRED environment, municipalities lost their fastest, most reliable way to reach residents.

Sensitive citizen data was stolen. Crisis24 informed customers that attackers extracted personal information including names, postal addresses, email addresses, phone numbers, and passwords. Because people reuse passwords across multiple accounts, municipalities now had to warn residents about risks far beyond the immediate emergency.

Attackers controlled part of the narrative. The INC group didn't just attack—they published. They posted sample data. They released what they claimed were ransom negotiation logs. According to those logs, INC started with demands near $950,000, later reduced to approximately $450,000, while Crisis24's supposed counteroffers of $100,000 and $150,000 were rejected before INC threatened to sell the data instead.

Trust fragmented across jurisdictions. Some stayed with Crisis24, betting on the company's promise of a newly hardened, separately hosted platform with additional security auditing. Others, like Douglas County, walked away entirely.

This isn't just about technology. It's about what happens when the system you rely on becomes the issue you need to fix.

Many crisis communication plans quietly rest on three dangerous assumptions:

Assumption 1: The primary alert system will be available when needed. The CodeRED incident proves this isn't guaranteed. Your most critical communication tool can disappear at the worst possible moment.

Assumption 2: IT or the vendor will restore service quickly. Recovery takes time. Sometimes days. Sometimes longer if the breach involves data theft requiring investigation and notification. During that window, your crisis compounds.

Assumption 3: Paying the ransom resolves everything. Even if organizations pay—and many don't, for legal, ethical, or policy reasons—the trust damage persists. Douglas County didn't wait to see if Crisis24 would recover. They moved on.

When your primary alert system fails, three things happen immediately:

Speed drops. You're forced to improvise across less efficient channels while the original emergency escalates.

Coverage shrinks. Not everyone checks social media. Not everyone visits municipal websites. Not everyone answers their door when someone knocks.

Clarity suffers. Now you're communicating both the original hazard—storm, fire, contamination, and the meta-crisis that your alert system is compromised and resident data may be at risk.

You don't need to work in government to learn from this. Any organization that relies on third-party platforms for critical outreach (email services, engagement apps, community portals, internal messaging) should be asking the same questions.

Start with brutal honesty.

What is our Plan A alert or communication platform in a crisis? Write it down. Name it specifically. Don't be vague.

What happens if it's offline, compromised, or untrustworthy for 48 to 72 hours? Walk through that scenario step by step. Where do the gaps appear?

Where is our audience not covered if we lose that platform? Which communities, demographics, or stakeholder groups fall through the cracks?

Then design alternative pathways:

Plan B: Secondary digital channels you control directly. Your website. Email lists you own. Pre-positioned social media content ready to deploy. Established relationships with media outlets who can rapidly amplify your messages.

Plan C: Low-tech and hyper-local options. Phone trees for critical contacts. Call centers with trained staff. Local radio partnerships. Printed notices at key locations. Physical signage. In public-sector contexts, door-to-door canvassing for life-safety situations.

If you can't articulate Plans B and C in writing today, those plans don't exist. They're just ideas you haven't tested.

The CodeRED incident forced municipalities into uncomfortable territory. They had to tell residents that the system meant to protect them was impaired. And that the personal data they provided might have been stolen. Those are not messages you want to draft under deadline pressure.

At minimum, prepare pre-approved templates for:

"Primary alert system disrupted": Explain what's down. Clarify which hazards (if any) are currently affected. Detail which channels you'll use instead. Keep it direct.

"Vendor cyber incident involving your data": Outline what happened in plain language. Specify what data is at risk. Explain what attackers might do with it. Provide specific protective steps like password changes, multi-factor authentication, and phishing vigilance.

FAQs for residents and internal stakeholders: Cover operational continuity questions like "How will you reach me now?" Address security concerns like "Was my financial data involved?" and "Should I trust future messages from this system?"

You can't predict every detail. But you can cut the time between "incident confirmed" and "message sent" from hours to minutes.

In the CodeRED case, the INC group tried to frame the story. They posted sample data. They published alleged negotiation logs to paint Crisis24 as uncooperative and increase pressure. This is standard ransomware playbook now.

Your plan should assume:

Ransom demands and negotiation snippets may be leaked publicly. Those leaks may be selective, distorted, or outright fabricated. Journalists and the public will see them and demand your response.

Work now—before any incident—with legal, security, and leadership to define:

Your organization's policy stance on ransom payment (pay, no pay, or conditional). The lines you won't cross in negotiation. The core messages you'll use if negotiations become public, emphasizing principle, legal and regulatory compliance, and concern for those affected.

When pressure mounts, you won't be inventing your ethics or your language on the fly. You'll be executing a plan.

Douglas County's decision to terminate its CodeRED contract sends a signal. Platform trust isn't guaranteed after a crisis, even with rebuilding and hardening efforts.

If you have any influence over procurement or vendor strategy, push for:

Contractual expectations about continuity and failover. Require backup data exports. Demand migration support. Establish SLAs for incident communication that specify timing, channels, and decision-maker access.

Clarity on shared responsibilities in a breach. Who notifies end users? Who answers media inquiries? Who owns which part of the public message? Don't discover these answers during the crisis.

Evidence of security and resilience, not marketing claims. Request third-party audits. Ask about penetration testing. Review the vendor's history of transparent incident handling. Past behavior predicts future performance.

You're not just buying a tool. You're buying a partner for your worst day.

On paper, a multi-channel, multi-vendor communication strategy looks impressive. In practice, it fails unless you rehearse.

Build into your calendar:

Tabletop exercises where you assume your primary platform is suddenly unavailable. Force the team to walk through, in real time, how they would move urgent messaging onto websites, social channels, and media partners. Practice informing stakeholders that the system is down without creating panic. Handle questions about data exposure and accountability.

Live drills (where appropriate) that test segments of Plan B and C. Deploy website banners. Activate SMS backup systems. Coordinate with local radio. The goal is identifying bottlenecks and training gaps before they matter.

The point isn't perfection. It's muscle memory.

Crisis24 is telling customers that the compromise was limited to the CodeRED environment. They're bringing online a new, separately hosted platform with extra hardening and security review. For some jurisdictions, that will be enough. For others, like Douglas County, the trust has already fractured beyond repair.

The real question for communicators:

When your primary channel fails or becomes implicated in a breach, will people still trust you enough to listen through your backup channels?

That answer depends less on technology and more on:

The transparency and speed of your initial disclosures. Did you tell people what happened quickly and honestly, or did information leak out through other sources first?

The credibility of your guidance to those at risk. Were your protective recommendations specific and actionable, or generic and unhelpful?

The visible seriousness with which you treat preparedness. Do you demonstrate, long before anything goes wrong, that you've thought through scenarios and built redundant systems?

The CodeRED incident is a painful reminder. Our tools can become our vulnerabilities overnight. But it's also an invitation for communication leaders to do what they do best: anticipate the stories that might be told about their organization on its worst day, and write a better one in advance.

That better story always includes more than one way to reach people. It includes Plans B and C that actually work when Plan A goes dark.

CodeRED is a mass notification system used by hundreds of US municipalities to send emergency alerts about weather events, AMBER alerts, evacuations, and other life-safety threats. It matters because it represents a single point of failure—when it went down in November 2025, entire jurisdictions lost their primary way to warn residents about immediate dangers.

Immediately shift to documented backup channels (Plan B). Notify stakeholders through alternative means that the primary system is unavailable. Quickly assess whether sensitive data was exposed. Pre-write template messages for these scenarios before they happen so you can respond in minutes, not hours.

Test backup communication systems quarterly through tabletop exercises and annually through live drills. After any significant vendor change, platform update, or organizational restructuring, run an additional exercise to identify new gaps.

An effective Plan B includes: your own website with banner alert capability, email lists you control directly, pre-positioned social media content, established media partnerships for rapid amplification, and documented processes for activating each channel. All content should be pre-approved and ready to deploy.

This decision must be made in advance with input from legal, security, and leadership teams, considering regulatory requirements, ethical principles, and organizational policy. Many jurisdictions and organizations have adopted no-ransom policies. Whatever the decision, it should be documented before an incident, not debated during one.

Breach notifications should specify in plain language: what happened, what data was affected, what attackers might do with that data, specific protective actions people should take immediately (password changes, multi-factor authentication), and where to find updates. Avoid technical jargon and legal language that obscures the actual risk.

Demand evidence, not assurances. Request copies of recent third-party security audits, penetration test results, and incident response plans. Review the vendor's public history of handling security incidents. Include specific security requirements and incident response obligations in contracts, with penalties for non-compliance.

Platform trust is foundational. If people doubt the integrity of the channel delivering emergency information, they won't act on warnings even when those warnings are accurate and urgent. Once platform trust breaks—as it did for Douglas County with CodeRED—rebuilding it is extremely difficult, often impossible.

Anticipate that ransom negotiations may become public through attacker disclosures. Prepare core messages in advance emphasizing your organization's principles, legal obligations, and commitment to protecting affected individuals. Never comment on specific negotiation details or amounts. Focus all public communication on actions being taken to protect those affected.

Assuming the primary communication platform will be available when needed. This single assumption undermines countless crisis plans. The biggest mistake is treating backup communication channels as theoretical rather than tested, resourced, and ready-to-deploy systems.

About the Author: Philippe Borremans is founder of RiskComms, specializing in crisis communication frameworks and emergency preparedness. With 25 years of experience in crisis communication, Philippe has developed proprietary frameworks including the Universal Adaptive Crisis Communication (UACC) Framework and the Minimum Viable Crisis Communication (MVCC) approach.