Suisun City Cyberattack: Keep 911 Recovery Credentials Out of Incident Chat

Suisun City, California, declared a state of emergency after malicious software compromised municipal IT systems and affected 911 routing, police and fire dispatch, records and other city services. The city shut down its IT network to contain the threat and preserve evidence, while dispatchers continued taking calls through the Solano County dispatch center.

The incident shows why continuity plans need a separate path for recovery credentials. When municipal email, chat, identity systems or endpoints may be inside the incident boundary, posting replacement passwords and recovery codes into the normal incident room can expose the very access responders are trying to restore.

What Suisun City confirms

The city says malicious software infected and compromised its IT systems at about 5:45 a.m. on August 7. On August 8, the City Council declared a state of emergency, allowing the city to obtain emergency support and recover incident-related costs.

According to the official declaration, the incident hit critical public-safety operations, including 911 routing, police and fire dispatch and records. The city activated its Emergency Operations Center and said it was working with the FBI, the Department of Homeland Security, the California Office of Emergency Services and regional partners.

This does not mean residents had no access to emergency help. The city said all public-safety services remained active: Suisun City dispatchers continued taking 911 and non-emergency calls through the Solano County dispatch center, while police and firefighters continued responding. KQED independently reported the declaration and operational disruption.

The city has not publicly identified the attacker, initial access path, malware family, ransom demand or any stolen data. The official wording is “malicious software,” so it would be premature to label the incident ransomware or claim that the 911 service was completely unavailable.

The incident chat is a coordination tool, not a recovery vault

During a network shutdown, responders often create temporary chat rooms, shared documents and email threads to coordinate work. Those tools are useful for assignments and status updates, but they are poor places for administrator passwords, backup codes, private keys and vendor access tokens.

A participant's account may be compromised, guest membership may be broader than expected, exports may preserve the full transcript and screenshots can outlive every retention setting. If responders paste a new credential into that environment, an intruder with continuing access can capture it immediately.

Prepare a clean credential channel before services fail

Define the alternate command structure. Document who can authorize access when the usual manager, identity provider or ticketing system is unavailable.
Maintain a verified offline contact list. Include primary and alternate owners for dispatch, networking, identity, cloud, telecoms and external response partners.
Classify recovery secrets. Separate values that can be issued temporarily from long-lived keys that require stronger custody or multi-person approval.
Choose a clean-device procedure. Specify how responders obtain and validate a workstation or phone outside the suspected compromise boundary.
Pre-stage minimum-privilege roles. Recovery should not require handing a broad domain administrator password to every vendor or responder.
Test the county and supplier handoffs. A failover plan is incomplete if the receiving organization cannot verify the caller or securely receive the credentials needed to operate it.

Use two separate planes during the response

Keep operational coordination and secret delivery separate. The incident room can say that access was approved, who owns the task and when it expires. The credential itself should travel through a controlled handoff to a verified recipient. This limits the blast radius if the transcript is later exposed.

Coordination plane: tasks, status, decisions, incident timestamps and non-secret references.
Secret plane: one authorized recipient or a pre-defined approval group, the minimum required value and a short validity period.
Target-system evidence: logs showing which identity was used, from where, for what action and when access ended.

Do not send the decryption material, a screenshot of the secret or a copied plaintext value back into the coordination plane as proof. Record the transfer event and the outcome instead.

A practical emergency credential lifecycle

Confirm that the requested action is necessary for public-safety continuity.
Verify the recipient through the pre-established contact method and confirm their current role.
Create or release a scoped credential with the shortest feasible lifetime.
Transfer it from a clean device without placing plaintext in ordinary email or chat.
Monitor use at the destination and stop access when the assigned task is complete.
Rotate or revoke the value, preserve non-secret audit evidence and review every exception made during the emergency.

Where Secretus can help

Secretus can reduce persistent plaintext copies when an authorized responder needs a temporary password, recovery code or scoped token. A short-lived, one-time Standard Mode link can replace pasting the value into the incident transcript. For a planned multi-person release, Team Split can distribute separate shares so the defined threshold must participate in reconstruction.

The transfer remains only one step in the control chain. Secretus does not authenticate the recipient's organizational role, clean a compromised device, provide 911 continuity or replace a privileged-access platform. A recipient can still copy a value, and a compromised browser can expose it. Verify identity independently, use a trusted endpoint and rotate the credential after use.

Questions for the next municipal tabletop

Can dispatch fail over while the city network is intentionally offline?
Which accounts are needed to activate telecom, CAD, records and identity recovery?
Can incident command verify a county dispatcher or vendor without municipal email?
Which recovery values have an offline contingency, and who can authorize their release?
How quickly can every temporary or exposed credential be revoked after restoration?
Does the final incident record prove authorization and use without storing the secret itself?

The goal is not to keep every system online at any cost. It is to preserve public-safety operations while containing the compromise—and to avoid rebuilding access on top of credentials that have already leaked into the response process.