IT Trends Weekly — a curated, citation-first roundup for busy IT leaders.

When government services go dark: lessons from Nevada & Maryland

Key takeaways

State and local agencies remain prime ransomware targets; when they’re hit, real-world services stop (websites, phone lines, paratransit scheduling). Build plans that assume temporary loss of core apps.
Treat public-facing portals and call centers as critical infrastructure: segment them, pre-plan manual workarounds, and rehearse the switch.
If you rely on a vendor’s platform (dispatch, payments, records), insist on functional continuity SLAs — not just “uptime” — and test them.

What happened (last week)

Nevada closed state offices for two days and took multiple sites and phone lines offline after a cyberattack was discovered, with staged restoration across the week^[1]^[2]. Officials later confirmed evidence of data exfiltration, though details were still being assessed^[3]^[4].

Maryland’s Transit Administration reported a cybersecurity incident that blocked new bookings for its Mobility/paratransit service while core bus/rail remained operational. The agency published interim workarounds and an emergency ride option during restoration^[5]^[6]^[7].

Why it matters

These weren’t abstract “IT outages.” Residents couldn’t reach state offices or schedule critical transportation. For enterprises, the lesson is blunt: if a key service or vendor platform goes down, can your teams still serve customers for days?

The enterprise angle: what to change now

Plan beyond backups. Containment may require taking systems offline — leaving sites and phones unusable for days^[1]. Define a manual or reduced-function mode you can activate within two hours: static status page, phone trees, simplified intake, spreadsheet queues.
Separate “read” from “write”. Maryland could keep riders informed but couldn’t accept new bookings — a classic asymmetry^[6]. Architect separate planes and restore read services first to cut call volume.
Publish functional fallbacks. Offer alternatives (e.g., emergency ride options) and post on a predictable cadence^[7]^[8].
Vendor risk = your risk. Add functional continuity SLAs to contracts: if the vendor can’t accept new requests, they must provide CSV intake by S+4 hours with daily re-ingest, named contacts, and tabletop participation.
Comms are product. Host a static comms site (separate DNS/cloud) that stays up even if your main stack is isolated; pre-approve plain-language templates and post updates at a fixed cadence (e.g., 10am/4pm local).

Security specifics to check this week

Identity & segmentation: separate admin planes; hardware-key MFA for privileged users; remove standing vendor access (use JIT).
Rapid isolation patterns: practice cutting to a CDN-hosted static page for your main site; keep phone trees on a separate provider.
Ransomware-assumed restore: prove you can accept new intake in a clean environment within 24–48 hours while historical systems are quarantined.
Tabletop two scenarios: portal encrypted (CSV/webform intake + manual queue) and scheduling down (temporary rules + call-in windows).
Measure readiness: MTTR for first public update (<60 min); time to functional continuity (intake on) vs. full restore.

Quick playbook

Within 48 hours: publish continuity pages for top 5 customer journeys; run a 60-minute tabletop; add functional continuity clauses to two active vendor contracts.
Within 2 weeks: build static failover for your main site; implement read/write separation; document contact/role trees and posting cadence.
Within 90 days: complete cross-vendor tabletop; deploy hardware-key MFA for admins and vendors; prove clean-env intake while quarantine continues.

Bottom line

Assume one of your core public-facing systems — or a vendor you depend on — will go dark. Your job isn’t just to restore; it’s to continue serving. Design for functional continuity, segment ruthlessly, and publish the playbook before you need it.