Industrial sensing systems face a security landscape that traditional OT protocols were never designed to address: internet-connected gateways, cloud-side data processing, third-party integrations, and an expanding attack surface that now spans from hardware probes to AI inference engines. This paper describes the security architecture of the MNEMOS platform — a zero-trust design that applies cryptographic verification at every trust boundary, from probe-to-gateway authentication via ECDSA-P256 on hardware secure elements, through TLS 1.3 in transit, to SHA-256 hashed gateway bearer tokens at the platform boundary. We document the complete threat model, describe each defensive control and the attack it mitigates, and provide implementation guidance for hardware manufacturers and gateway developers building PDP-compliant systems.
The MNEMOS threat model considers adversaries with the following capabilities: physical access to deployed probes and gateways; passive interception of bus traffic between probe and gateway; active man-in-the-middle injection on the gateway-to-broker MQTT connection; access to gateway firmware images; and read access to the platform database (e.g. through a compromised ORM injection). We explicitly do not model adversaries with the capability to break ECDSA-P256 or AES-256 — these are computationally infeasible with known techniques.
| Threat | Actor | Severity | Mitigations |
|---|---|---|---|
| Counterfeit probe injecting false measurements | Supply chain attacker, state actor | CRITICAL | ECDSA AuthCRL |
| EEPROM tampering to alter calibration coefficients | Insider threat, physical access | HIGH | TEDS Sig |
| Replay attack: replaying captured measurement frames | Network attacker | MEDIUM | SEQ CounterTLS |
| Gateway credential theft to inject data at platform level | Compromised IT system, insider | HIGH | SHA-256 HashToken Rotation |
| MQTT man-in-the-middle: intercept or modify ingest payloads | Network attacker, lateral movement | HIGH | TLS 1.3Cert Pinning |
| SQL injection / ORM injection via ingest payload | Attacker controlling a gateway | MEDIUM | Parameterised SQLDRF Validation |
| Gateway token theft from firmware image | Reverse engineer, insider | MEDIUM | Per-device tokensRevocation |
| Platform database read: exposure of historical measurements | DB compromise | MEDIUM | No plaintext tokensOrg isolation |
| Denial of service via measurement flood | Compromised gateway | LOW | 5k batch limitRate limiting |
Zero-trust architecture holds that no entity — whether inside or outside the network perimeter — is trusted by default. Every access request must be verified, regardless of where it originates. For digital systems, zero-trust has been operationalised through mutual TLS, JWT bearer tokens, and continuous verification of device posture. For physical sensing systems, zero-trust requires an additional layer: verification of the physical hardware itself, not just the software running on it.
The MNEMOS security architecture applies zero-trust at three distinct boundaries:
This contrasts sharply with traditional OT security models, which relied on network segmentation as the primary defence. Air-gapped networks and DMZ architectures assumed that anything inside the perimeter was trustworthy. Modern OT environments — with cloud connectivity, remote maintenance access, and supply chain components from dozens of vendors — cannot make that assumption. Zero-trust is not an optional enhancement for connected physical systems; it is a prerequisite for safe operation.
The foundation of PDP security is the secure element — a tamper-resistant hardware component that generates, stores, and uses the probe's ECDSA-P256 private key without ever exposing it to the probe's main processor. The reference implementation uses the Microchip ATECC608B, which costs approximately $0.50 at volume and is available in a 3mm × 2mm UDFN package suitable for compact probe PCBs.
Private key generation occurs inside the secure element during probe manufacture, using its internal hardware random number generator. The key never leaves the secure element and cannot be extracted via any documented interface — the ATECC608B's hardware security architecture blocks key read-out through software and resists physical fault injection (glitching, power analysis) through built-in countermeasures.
At manufacture, the probe's public key is read from the secure element, combined with the probe's hardware_id and manufacturer metadata, and signed by the manufacturer's intermediate CA to produce the device certificate. This certificate is written to the probe's TEDS EEPROM (offset 0x0230). The private key never leaves the factory — only the signed certificate.
The ATECC608B is configured with the following zone permissions during provisioning:
PDP authentication uses a mutual challenge-response protocol. The choice of ECDSA-P256 (NIST P-256 / secp256r1) balances security — 128-bit equivalent security level — against the computational constraints of embedded microcontrollers. P-256 signature generation takes approximately 0.5ms on an ARM Cortex-M4 at 120 MHz, which is well within the sub-500ms Phase 2 budget specified in the PDP lifecycle.
The session field in the first AUTH_CHALLENGE is the session address assigned in Phase 1 enumeration. Including it in the signed data prevents cross-session replay: an AUTH_RESPONSE from session 3 cannot be replayed in session 7, because the session byte in the signature would not match.
Authentication failure results in: immediate disconnect; an AUTH_FAILED event written to the platform log (device_id if extractable from certificate, otherwise public key fingerprint); a mandatory 5-second reconnect lockout on the physical port; and an increment of the failure counter for the hardware_id. After 5 consecutive failures from the same hardware_id within 60 seconds, the gateway blacklists that ID for 10 minutes and alerts the platform. This rate-limiting prevents brute-force attacks on the authentication protocol.
The PDP certificate hierarchy has three levels:
The PDP CRL is a signed JSON document listing revoked device certificate serial numbers, grouped by manufacturer Intermediate CA. It is distributed via the Vigil API and cached on each gateway. Gateways must refresh the CRL at every MQTT reconnect and must not accept probe connections that cannot be verified against the current CRL. A gateway that has been offline for more than 72 hours must refuse new probe connections until it refreshes the CRL, preventing stale revocation data from creating a persistent security window.
Gateway-to-platform authentication uses a separate mechanism from probe-to-gateway authentication. The decoupling is intentional: compromise of a platform gateway token does not expose probe private keys, and vice versa. Gateway tokens use a simpler, stateless scheme based on opaque bearer tokens and one-way hashing.
gw_secrets.token_urlsafe(40)On each API call, the gateway includes the raw token in the Authorization: Bearer gw_... header. The platform computes SHA-256(raw_key) and performs a single indexed database lookup against the key_hash column. There is no timing-sensitive comparison: since the hash lookup is indexed and returns at most one row, timing side-channels are not a meaningful attack vector.
python manage.py issue_gateway_token. Plaintext shown once to the operator, stored in firmware/config manager, never logged or stored on the platform.is_active=False on the GatewayToken record. Takes effect on the next API call — no restart required. The gateway token is checked on every ingest call, so revocation propagates within seconds.expires_at on the token for temporary deployment access or contractor credentials. The platform checks expires_at on every authentication and returns 401 for expired tokens.All communication between the gateway and the Vigil platform (both MQTT and HTTPS) uses TLS 1.3 with mutual authentication. TLS 1.3 eliminates the negotiation vulnerabilities present in TLS 1.2 (BEAST, POODLE, CRIME, Lucky-13) and removes all deprecated cipher suites from the handshake, accepting only AEAD cipher suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, and TLS_AES_128_GCM_SHA256.
The reference Mosquitto broker configuration enables:
require_certificate true) — gateways present a TLS client certificate in addition to MQTT credentialsGateways authenticate to the platform with two credentials: a TLS client certificate (proving they are a known hardware device) and a gateway bearer token in the HTTP header (proving they have been authorised by a platform administrator to ingest data for a specific organisation). This two-factor approach means that even if an attacker obtains a valid bearer token (e.g. by reading a gateway's config file), they cannot use it without also having a valid TLS client certificate — which requires access to the gateway's certificate private key.
The TEDS EEPROM is the ground truth for a probe's identity, calibration, and channel configuration. Tampering with it — by modifying calibration coefficients, injecting a different certificate, or altering channel quantity codes — could cause the platform to silently accept false measurements. The TEDS security design prevents this through a combination of hardware access control and cryptographic signing.
After provisioning, the TEDS EEPROM's write-protect pin is tied permanently high via a solder jumper on the probe PCB. This is a one-way, non-reversible operation that prevents any write to the EEPROM in the field — including by the probe's own microcontroller. The only way to alter the EEPROM after write-protect is set is physical de-soldering of the component, which is clearly destructive and visible on inspection.
Even if an attacker overcomes the hardware write protection (e.g. by replacing the EEPROM with a modified one), the ECDSA-P256 signature over the entire TEDS data region (bytes 0x0000–0x042F) will fail verification because the attacker does not have the probe's private key (held in the secure element). Any modification to calibration coefficients, channel tables, or the certificate region invalidates the signature, and the gateway rejects the probe with a TEDS_INTEGRITY_FAILURE event.
The MNEMOS platform maintains a comprehensive audit trail covering all security-relevant events. Logs are structured JSON, written to stdout (captured by the container runtime) and optionally streamed to an external SIEM.
In the event of a suspected security incident — compromised gateway token, rogue probe, or unusual measurement patterns — the recommended response procedure is:
is_active=False on the suspected gateway token to halt further data ingestion from that gateway.AlertNotification and authentication failure logs for the affected gateway and time window.The MNEMOS security architecture is designed to support compliance with major industrial cybersecurity frameworks. The following mapping is indicative; formal compliance assessments require engagement with a qualified third-party auditor.
IEC 62443 (Industrial Automation and Control Systems Security) defines Security Levels (SL) 1–4. The MNEMOS PDP authentication and TEDS integrity controls align with SL-2 (protection against intentional violation using simple means) and partially with SL-3 (protection against sophisticated attacks). Achieving full SL-3 compliance requires additional controls including physical tamper detection on gateway enclosures and hardware security modules for gateway private key storage — outside the scope of the current PDP specification but noted for future revision.
PDP security controls map to the following NIST CSF functions: Identify (hardware inventory via automatic probe registration), Protect (ECDSA authentication, TLS, write-protect EEPROM), Detect (authentication failure logging, anomaly alerts), Respond (token revocation, CRL update), and Recover (token rotation, re-provisioning procedure).
The Vigil platform layer is designed for SOC 2 Type II readiness: all authentication events are logged with timestamps and actor identity; no plaintext credentials are stored; access controls are role-based (organisation-scoped) with audit trails; data retention and deletion are configurable per organisation.
The security architecture described in this paper reflects a single design conviction: in connected physical systems, security cannot be retrofitted. It must be designed in from the hardware layer upward. ECDSA-P256 on secure elements ensures that probe identity is hardware-bound and cannot be cloned. TEDS EEPROM signatures ensure that calibration data cannot be altered. SHA-256 hashed gateway tokens ensure that platform credentials are never stored in recoverable form. TLS 1.3 ensures that none of this is visible to a network attacker.
The result is a stack where every trust boundary is explicitly verified, every security event is logged, and every credential can be revoked without service interruption. This is zero-trust applied to the physical world — and it is the only architecture appropriate for sensing infrastructure that is expected to operate safely for decades, in environments where physical access cannot be fully controlled and where the consequences of false measurements include equipment damage, production loss, and potential safety incidents.
We invite security researchers to review this architecture and the accompanying PDP specification. Responsible disclosure can be submitted to security@continuislabs.io. We maintain a public security advisory page and commit to patching critical vulnerabilities within 72 hours of confirmed disclosure.