How paramant supports IEC 62443 compliance

SR 4.1 requires the IACS to protect the confidentiality of information at rest and in transit as required to meet the target Security Level (SL-T).

Transit protection: All data transported via paramant is encrypted client-side before transmission using ML-KEM-768 (post-quantum key encapsulation per NIST FIPS 203) combined with ECDH X25519. Decryption requires the receiver’s private key, which never leaves the receiver’s device. The relay never holds a decryption key.

No data at rest: Paramant stores no payload on disk. Files reside in RAM only and are deleted upon first download (burn-on-read). The concept of “data at rest” is structurally eliminated for transit events. An attacker who gains access to the relay server finds no stored data.

Ciphertext padding: All transfers are padded to a fixed 5 MB block, preventing traffic analysis based on file size — relevant for SCADA environments where message patterns carry operational meaning.

IEC 62443-3-2 requires assets to be grouped into security zones. Communication between zones must traverse defined conduits with security controls. SR 5.1 requires the system to separate networks and communications into different security zones.

Dedicated IoT conduit: Paramant provides a dedicated relay sector at iot.paramant.app that is isolated at the application and network level from all other sectors (relay, health, legal, finance). Traffic from OT environments is never co-mingled with other sectors.

Conduit as a service: The paramant relay acts as the conduit between your OT zone and a receiving IT zone or cloud system. Data enters the conduit encrypted and exits as ciphertext. The conduit itself cannot decrypt the payload. This mirrors the IEC 62443 principle of a managed, controlled communication path with no persistent data in the conduit.

Self-hosted option: Operators with strict zone control requirements can deploy paramant relay entirely within their own infrastructure, maintaining full network topology control without any dependency on the managed cloud service.

SR 3.1 requires the IACS to protect the integrity of transmitted information to detect and correct errors and detect and deter tampering.

Cryptographic integrity: The paramant wire format includes an AEAD authentication tag (AES-256-GCM). Any modification of the ciphertext in transit — whether by a network attacker or a compromised relay — causes decryption to fail with an authentication error. Tampered transfers are rejected, not silently accepted.

CT log integrity: Every key registration is appended to a Merkle tree. The tree root hash is published at health.paramant.app/v2/ct/log. Any retroactive modification of a log entry invalidates all subsequent tree hashes, making tampering immediately detectable by any verifier who holds the expected root.

ML-DSA-65 relay identity: Each relay instance signs its registration with ML-DSA-65 (NIST FIPS 204, post-quantum digital signature). A relay claiming a known identity cannot be impersonated without the corresponding signing key.

IEC 62443-2-3 addresses patch management and the security of supplier relationships. IEC 62443-2-1 requires a documented security program for the IACS components in use.

Minimal attack surface: The relay binary has 22 runtime dependencies, all present in the public npm registry with reproducible builds. The Docker image is built from Alpine Linux with a non-root relay process and a read-only filesystem. No shell access is exposed at runtime.

Publicly audited: The relay software is open source under BUSL-1.1. An independent security audit (RAPTOR methodology, April 2026) is available and documents all findings and remediations. Operators can verify that findings have been addressed before deployment.

Versioned releases: All relay releases are tagged, signed, and published on GitHub and Docker Hub (mtty001/relay). Patch history is publicly traceable. Operators receive upgrade paths without hidden changes.