Ideas, observations, and useful links from CTS Companies.

A resilient communication plan is often drawn as a network diagram. That is useful, but incomplete.

NIST’s recent work on 5G Sidelink looks at direct device-to-device communication when ordinary network infrastructure is unavailable. Its public-safety example is deliberately demanding: responders may need voice, mapping, video, location, discovery, and group coordination in places where the network cannot reach them. NIST also describes real limits, including range, congestion from relaying, and immature device availability.

The useful business lesson is smaller: when the network is gone, the workflow does not vanish. Someone may still need to authorize a decision, identify a location, coordinate a team, verify a customer, or record what happened.

Resilience planning gets sharper when it names those functions instead of merely naming a backup connection. What information must travel? Who can approve an exception? What still needs identity or location data? What can be written down and reconciled later? Which coordination path works if the usual one does not?

A second circuit is helpful. A fallback workflow is what turns it into continuity.

Source

NIST: Enhancing Public Safety Communication Reliability Through 5G Sidelink

A connected device arrives with a small but consequential invisible attachment: its last update.

That could be a camera, a conference-room controller, a router, a medical-adjacent sensor, a point-of-sale peripheral, or the oddly important appliance that someone bought because it solved Tuesday’s problem. The purchase order records the price. It often does not record who will receive security notices, apply updates, decide whether an update may interrupt work, or replace the device when support ends.

NIST’s current IoT guidance treats secure updating, customer information, and end-of-support communication as part of a product’s cybersecurity lifecycle—not as optional accessories. That is a useful buying model for any organization, even when the device is not glamorous enough to make the security committee agenda.

Before approving a connected device, ask four plain questions: Who owns it? How is it updated? When does vendor support end? What is the retirement plan? If those answers do not exist, the device is not fully purchased. It is merely installed.

The Department of Energy recently announced GridFM 2.0, a research project intended to help utilities evaluate far more possible grid scenarios, far more quickly. That is a real advance in planning capacity: more contingencies can be tested, more options can be compared, and fewer important cases need to be discarded merely because a model takes too long to run.

But a faster model is not a faster decision.

Every scenario still begins with choices. What demand is assumed? Which failure modes count? What cost, reliability, or service tradeoff is acceptable? A system can make those choices more visible and make their consequences easier to compare. It cannot decide which assumptions the organization is willing to own.

That distinction matters well beyond the grid. A finance model, a security dashboard, or an AI assistant can produce more possibilities than a team could review manually. The useful question is not whether the tool reached an answer. It is whether someone can explain the inputs, the alternatives rejected, and the reason this particular path was chosen.

Good technology expands the decision room. It does not remove the person responsible for the decision.

Michigan has received $2,346,859 in FY 2025 State and Local Cybersecurity Grant Program funding. The useful current fact is less exciting than a deadline: the state says the application period and submission deadline are still to be determined.

That means local governments should not treat an old form, an informal date, or a circulating attachment as an open invitation to apply. Wait for the state’s active instructions. But do not wait to identify the work.

Michigan describes the program as a reimbursable pass-through effort to help local, tribal, and territorial governments improve cybersecurity governance, assess their posture, implement protections, and train people responsible for the work. FY 2025 also carries a 40% cost-share requirement.

The strongest future project may begin with an ordinary operational problem: a backup that has not been restored, remote access that needs a better owner, an exposed public service, a gap revealed by an assessment, or a staff responsibility that has never had training behind it.

Write down the problem, the affected service, the evidence, the likely owner, and the recurring cost. When Michigan announces an application period, that small amount of preparation will be more useful than trying to invent a cybersecurity project in the last week.

Source: Michigan DTMB State and Local Cybersecurity Grant Program.

Municipal cybersecurity has improved considerably. Email, employee computers, servers, identity systems, and other traditional IT increasingly receive familiar protections: multifactor authentication, endpoint security, monitoring, backups, and stronger access controls.

The harder problem may be the infrastructure behind the municipality.

Water and wastewater systems rely on operational technology: specialized systems that monitor and control physical equipment. That includes programmable logic controllers operating pumps, valves, pressure, and treatment processes, along with the interfaces operators use to supervise them.

These environments can be harder to secure than an office network. Equipment can remain in service for decades. Availability is essential. Some devices were designed when outside connectivity was unusual, and replacing or patching them is not as simple as updating a PC.

Attackers have noticed. Recent federal advisories describe active targeting of internet-connected industrial controllers, including systems used across water and wastewater infrastructure. The lesson is broader than any single manufacturer or campaign: inventory, network separation, controlled remote access, monitoring, and rehearsed manual operations belong in a municipal security program too.

Securing City Hall is one problem. Securing the systems that make the city work is another.

“We have backups” sounds like an answer, but it is usually the beginning of the conversation.

A backup can exist and still be too old, too slow to restore, too dependent on one administrator, or too connected to the same environment it is meant to rescue. The practical question is: if the primary system disappeared this morning, what would we do first, and how long would that step take?

That question shifts attention from the product to the recovery sequence. Who declares the incident? Who knows which systems matter most? Where are the instructions? What can be restored without waiting for a vendor representative to explain the interface?

For a 20–100-person organization, a small recovery exercise is often more informative than another backup dashboard. Pick one important system. Restore a representative file or service. Write down every surprise.

The backup is the stored data. The real safeguard is the organization’s ability to use it.

Multi-factor authentication is often treated like a light switch: turn it on, receive a compliance-shaped glow, and move on.

But MFA changes the question. Once a business asks people to prove who they are with more than a password, it also has to decide what happens when the phone is lost, the authenticator is replaced, an employee leaves, or an attacker convinces someone to approve a request.

The useful question is not “Do we have MFA?” It is “Can the right person recover access without creating a new hole?” That requires documented recovery, a short list of people who can reset authentication, and a review of which accounts have more power than they need.

MFA is valuable because it makes stolen passwords less useful. It becomes much more valuable when the surrounding process does not turn account recovery into an informal help-desk conversation with no record.

For a small business, the next step after enabling MFA is simple: test the recovery path with someone who is not the person who designed it.