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: ParaShare authenticated transfers are encrypted client-side before transmission using ML-KEM-768 (post-quantum key encapsulation per NIST FIPS 203) combined with ECDH P-256. 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: ParaShare authenticated 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.

SR 4.2 requires the IACS to enforce authorisation, ensuring that only authenticated identities can access information or initiate transfers.

API key per device: Every sender and receiver must present a valid API key (X-Api-Key header). The relay rejects requests without a valid key. Operator installations use plk_ keys with unlimited quota; field devices use pgp_ keys with per-day rate limits.

Download requires knowledge of hash: Retrieval requires the blob hash, which is only known to the sender. An authenticated caller who does not hold the hash cannot enumerate or retrieve blobs belonging to other transfers.

max_views enforcement: Each blob is destroyed after a configured maximum number of downloads (default: 1). A second download attempt returns 404, preventing replay or eavesdropping by a party who intercepts the hash.

SR 1.1 requires that all users (human or device) be uniquely identified before access is granted. In OT contexts this extends to machine-to-machine identities for PLCs, gateways, and sensors.

DID enrollment: Field devices register a persistent identity via POST /v2/did/register. Each device submits a device ID string and an ECDH public key. The relay derives a W3C-compatible DID (did:paramant:<hash>) and appends the registration to the public CT log. The CT index provides a timestamped, tamper-evident record of when the device identity was established.

DID document resolution: Any auditor or integrator can resolve a device identity via GET /v2/did/:did to retrieve the public key, registration timestamp, and CT proof. This supports zero-trust device verification without a central directory.