FIPS-Validated Encryption for OT Networks.
Access Gate embeds multiple cryptographic modules. All cipher suites are NIST-approved and FIPS-compliant per SP 800-52. Encryption is enforced at the proxy layer without modifying production equipment.
How Access Gate encrypts CUI in transit
Industrial protocols like Modbus, EtherNet/IP, and DNP3 transmit in plaintext. The equipment running these protocols cannot be updated to support TLS. Access Gate solves this by encrypting traffic between the user and the proxy using FIPS-validated cipher suites. The plaintext segment between the proxy and the production machine is isolated within a micro-DMZ with no external egress. This satisfies NIST 800-171 SC 3.13.8 (encryption of CUI in transit) as a compensating control.
TLS 1.3 Cipher Suites.
TLS 1.3 suites used by Access Gate. All provide perfect forward secrecy by design. These are the preferred suites and are negotiated first.
| Cipher Suite | Status | Reference |
|---|---|---|
| TLS_AES_128_GCM_SHA256 | FIPS | TLS 1.3, NIST SP 800-52, FIPS 197 (AES-128) |
| TLS_AES_256_GCM_SHA384 | FIPS | TLS 1.3, NIST SP 800-52, FIPS 197 (AES-256) |
TLS 1.2 Cipher Suites.
TLS 1.2 suites supported for backward compatibility with older clients. ECDHE suites provide perfect forward secrecy. RSA key exchange suites are FIPS-approved but do not provide PFS.
| Cipher Suite | Status | PFS | Note |
|---|---|---|---|
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | FIPS | Yes | ECDHE key exchange, forward secrecy |
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | FIPS | Yes | ECDHE key exchange, forward secrecy |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | FIPS | Yes | ECDHE key exchange, forward secrecy |
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | FIPS | Yes | ECDHE key exchange, forward secrecy |
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | FIPS | Yes | CBC mode, forward secrecy |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 | FIPS | Yes | CBC mode, forward secrecy |
| TLS_RSA_WITH_AES_128_GCM_SHA256 | FIPS | No | No perfect forward secrecy |
| TLS_RSA_WITH_AES_256_GCM_SHA384 | FIPS | No | No perfect forward secrecy |
| TLS_RSA_WITH_AES_128_CBC_SHA256 | FIPS | No | No perfect forward secrecy |
Note on PFS: Suites without perfect forward secrecy (PFS) are FIPS-approved but should be deprioritized. If a private key is compromised, past sessions encrypted with non-PFS suites can be decrypted. Access Gate negotiates ECDHE suites first. RSA-only suites are available as a fallback for legacy clients.
Encryption Without Touching Equipment.
Proxy-Layer Enforcement
Encryption happens at the Access Gate proxy. CNC mills, labeling systems, and quality scanners continue using their native protocols unchanged. No firmware updates required.
Micro-DMZ Isolation
The plaintext segment between proxy and production machine is contained in an isolated micro-DMZ. No route to the internet or other network segments. Lateral movement is blocked.
CMMC SC 3.13.8 Evidence
Access Gate generates TLS configuration exports, cipher negotiation logs, and micro-DMZ network diagrams. All evidence required for C3PAO assessment of the encryption compensating control.
CMMC Shared Responsibility Matrix
SC 3.13.8 encryption requirements and how Access Gate satisfies them.
Read moreCMMC Enduring Exception for OT
Compensating controls for equipment that cannot encrypt natively.
Read moreCMMC Compliance for On-Premise
Full CMMC resource hub with case studies, guides, and blog articles.
Read moreEncryption FAQ.
All cipher suites embedded in Access Gate are NIST-approved per FIPS 197 (AES) and SP 800-52 (TLS configuration).
Access Gate uses cryptographic modules that implement FIPS-approved algorithms (AES-128, AES-256, SHA-256, SHA-384, ECDHE, RSA). The specific TLS implementation uses the Go standard library crypto/tls package with FIPS-compliant cipher suites. Refer to the datasheet for current certification status.
Access Gate prefers TLS 1.3 suites first (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256). If the client does not support TLS 1.3, it falls back to TLS 1.2 ECDHE suites with GCM mode. RSA-only suites are negotiated only as a last resort.
The user connects to Access Gate over TLS. Access Gate terminates the encrypted session and forwards traffic to the production machine over its native protocol (Modbus TCP, EtherNet/IP, etc.) within an isolated micro-DMZ. The plaintext segment has no external egress.
SC 3.13.8 requires encryption of CUI in transit. For OT assets that cannot encrypt natively, Access Gate provides a compensating control: TLS encryption on the user-to-proxy path, with the plaintext segment isolated in a micro-DMZ. This is documented as an Enduring Exception with the proxy architecture as the compensating control.
NIS2 Article 21 requires appropriate encryption for network communications. Access Gate satisfies this with FIPS-validated TLS on all access paths. The same cipher suites and architecture apply to both CMMC and NIS2 deployments.
Yes. Access Gate policy configuration allows you to restrict which cipher suites are available. You can disable RSA-only suites entirely and require ECDHE for all connections. This is recommended for new deployments where all clients support ECDHE.
Review the Encryption Architecture.
The Trout team can walk through the cipher suite configuration, micro-DMZ architecture, and CMMC evidence generation for your environment.
Contact Us