In the previous article, I wrote about WiFi fingerprinting as a possible sensing layer for physical security.

The idea was simple enough to explain:

Can a Linux-based system detect meaningful changes in a physical space without using a camera?

That question leads naturally to the next one.

If the system detects something important, can it still report it when the normal network is unavailable?

Detection is only useful if the signal can still leave the site.

A security event that cannot leave the building is only a local observation.

The Hidden Assumption in Monitoring

Many modern monitoring and security systems assume that some form of connectivity will always be available.

They expect at least one of these paths to work:

  • Ethernet,
  • WiFi,
  • internet uplink,
  • mobile network,
  • cloud service,
  • VPN,
  • central SIEM,
  • remote notification channel.

In normal operations, that assumption is usually fine.

During an incident, it may not be.

A damaged fibre link, a failed switch, a power event, an operator outage, a misconfigured firewall rule or a local routing mistake may be enough to isolate a site from the systems that are supposed to receive its alerts.

That creates an uncomfortable situation.

The sensors may still detect the event.

The local system may still know that something happened.

But the information may not reach anyone who can act on it.

Detection without delivery is an incomplete security system.

Why I Started Looking at MeshCore

While thinking about resilient event delivery, I started looking at MeshCore.

MeshCore describes itself as an off-grid mesh communication system. Its public documentation and official site present it as a way to exchange small messages through a mesh of devices, without depending on internet connectivity or a mobile operator.[1][2]

The project is also public on GitHub, which makes it easier to inspect as a candidate technology rather than treat it as a black box.[3]

The part that interests me is not the gadget aspect.

It is the architectural possibility.

Could a low-bandwidth LoRa mesh become a backup communication layer for critical security signals?

Not for video.

Not for log streams.

Not for normal operations.

For the message that should not disappear when the normal network fails.

What LoRa Mesh Is Good For

LoRa mesh is not interesting because it is fast.

It is interesting because it may still be available when fast networks are not.

A security system usually does not need to send gigabytes during an emergency. It may only need to send a very small message:

SERVERROOM: movement detected
UPS: battery 8%
FIREWALL: offline
DOOR-3: opened after hours
NODE-17: integrity change detected

For that type of communication, a few reliable bytes may matter more than a broadband connection.

This is where MeshCore becomes interesting as a research direction.

It offers a way to think about small messages moving through a decentralized mesh, potentially through repeaters, without assuming that the usual IP path is alive.[1][2]

That does not make it a universal answer.

It makes it a candidate for a very specific layer:

emergency, low-bandwidth, out-of-band security telemetry.

What It Is Not For

It is important not to overclaim.

MeshCore and LoRa-style mesh communication are not replacements for normal network infrastructure.

They are not suitable for camera feeds.

They are not suitable for large telemetry streams.

They are not a replacement for Ethernet, WiFi, LTE, fibre, VPN or cloud messaging.

And they are not a guarantee that every message will always arrive under every condition.

The value is different.

The value is having another path.

The goal is not to replace the primary infrastructure.

The goal is to survive its failure better.

A Multi-Path Security Architecture

The architecture I am interested in is layered.

In normal operation, a node should use the best available communication path:

Primary path:
Ethernet / WiFi / local IP network

Secondary path:
LTE / alternative uplink / another routed path

Emergency path:
LoRa mesh / MeshCore / low-bandwidth out-of-band message

The last layer is not for convenience.

It is not for routine dashboards.

It is for the critical message that should not be lost.

A practical system could decide:

  1. send the event through the normal network,
  2. retry through an alternative IP path,
  3. if that fails, compress the event into a small emergency message,
  4. send it through the mesh,
  5. keep local evidence for later reconciliation.

That last step matters.

If the emergency path only sends a short message, the local node still needs to preserve the richer evidence:

  • timestamp,
  • event source,
  • confidence level,
  • sensor data summary,
  • integrity status,
  • correlation context,
  • and audit trail.

The mesh does not need to carry everything.

It only needs to carry enough to say:

Something important happened. Investigate this node.

Where This Connects to WiFi Fingerprint

The previous WiFi Fingerprint article asked one question:

Can we sense that something changed in a physical space?

The MeshCore question is the next layer:

Can we still report it when the normal network is gone?

Those two ideas naturally fit together.

One module detects that something may be happening.

Another communication layer tries to make sure that the signal is not trapped locally.

The point is not to create a dramatic alarm for every weak signal.

The point is to build resilience into the path between detection and action.

A WiFi fingerprint event may be only one input.

It may need correlation with access control, door sensors, system integrity, time rules or administrator schedules.

But if the local network is down, even that first signal may be valuable.

A short emergency message may be enough:

TCS-NODE-04: physical anomaly after hours

Not a full incident report.

A prompt to investigate.

Security Telemetry Should Not Depend on One Medium

Modern security architecture often spends a lot of time on detection logic.

That is necessary.

But detection is only one part of the chain.

For TCS, I do not want to think only about detection. I want to think about the full path of a security signal:

created → validated → transported → correlated → preserved as evidence

Transport is often treated as boring plumbing.

It is not.

If the transport layer fails during exactly the situation where we need it, the rest of the system becomes much weaker.

That is why resilient telemetry matters.

Not every event needs an emergency channel.

But some do.

A UPS battery warning during a network outage may matter.

A firewall offline event may matter.

A server room movement event after hours may matter.

A system integrity change on an isolated node may matter.

Those are not high-bandwidth events.

They are high-importance events.

What This Could Mean for TCS

I am researching MeshCore as a possible future component or integration direction for TCS / Trace Core Security.

I am not claiming that MeshCore is the final answer.

I am treating it as a candidate technology for a resilient, low-bandwidth, out-of-band communication layer.

The goal is not to build another monitoring system.

The goal is to explore a security platform that can:

  • detect events,
  • classify their importance,
  • choose an available communication path,
  • send a minimal emergency message when needed,
  • preserve local evidence,
  • and reconcile the full event history when connectivity returns.

That is a different kind of architecture.

It does not assume that the network is always healthy.

It assumes that infrastructure can degrade.

And it designs for that degradation from the beginning.

Open Questions

There are still many practical questions to answer.

For example:

  • How reliable is message delivery in real deployments?
  • How should messages be prioritized?
  • How should replay, duplication and stale alerts be handled?
  • How should encryption and authentication be implemented for security events?
  • How should node identity be verified?
  • How do we prevent false trust in a low-bandwidth emergency signal?
  • How should local evidence be preserved until normal connectivity returns?
  • What is the correct operational model for repeaters?
  • What happens when the mesh itself is unavailable?

These questions are exactly why I treat this as research, not as a finished solution.

But the direction is important.

Security systems should not only ask:

Did we detect the event?

They should also ask:

Can the event still reach the right place when the infrastructure is degraded?

The Larger Direction

The first article was about sensing.

This one is about delivery.

Together, they describe a larger direction for TCS:

sense the environment
validate the event
deliver the signal
preserve the evidence
correlate the context

That is the kind of security system I want to build toward.

Not a collection of isolated sensors.

Not a dashboard that only works when everything else works.

A resilient evidence system that understands that incidents often happen when normal infrastructure is already under stress.

For emergency security telemetry, speed is not always the most important property.

Sometimes resilience matters more.

Sometimes the most important message is not large.

It is just the one that still gets through.

Sources

[1] MeshCore — Off-Grid Mesh Communication: https://meshcore.co.uk

[2] MeshCore official site: https://meshcore.io

[3] MeshCore GitHub repository: https://github.com/meshcore-dev/MeshCore