FIPS-validated encryption, without touching machines.
Access Gate encrypts every session at the proxy. Production machines stay as they are. Every cipher suite is NIST-approved and FIPS-compliant per SP 800-52.
Last updated:
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.
What is validated and where to check it.
A FIPS claim only counts if it names the module and its certificate. Access Gate does not ship cryptography we wrote. The approved algorithms come from a FIPS 140-3 validated kernel cryptographic module. It is listed below with its CMVP certificate, so you can check it against NIST yourself.
- Module
- Kernel Cryptography Module for AlmaLinux 9
- Vendor
- CloudLinux Inc., TuxCare division
- Standard
- FIPS 140-3, Overall Level 1
- CMVP certificate
- #4750, validated 2 August 2024, updated 7 August 2025
- Module type
- Software, multi-chip stand alone
One thing worth stating accurately when you write this into an SSP. NIST validates cryptographic modules and issues certificate numbers; it does not certify products. So the precise, defensible claim is that Access Gate uses a FIPS 140-3 validated module under certificate #4750, and that is the form an assessor can check against the CMVP listing.
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.
Machines keep their native protocols.
Encryption at the proxy.
Encryption happens at the Access Gate proxy. CNC mills, labeling systems, and quality scanners continue using their native protocols unchanged. No firmware updates required.
Plaintext stays in a micro-DMZ.
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.
Evidence for CMMC SC 3.13.8.
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.
Questions about FIPS encryption.
All cipher suites embedded in Access Gate are NIST-approved per FIPS 197 (AES) and SP 800-52 (TLS configuration).
Access Gate uses a FIPS 140-3 validated module, CMVP certificate #4750. NIST validates modules, not products. The approved algorithms include AES-128, AES-256, SHA-256, SHA-384, ECDHE and RSA. TLS runs on the Go standard library crypto/tls package with FIPS-compliant cipher suites.
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.
IEC 62443 expects communications between zones to be protected with appropriate cryptography. Access Gate satisfies this with FIPS-validated TLS on all access paths. The same cipher suites and architecture apply to both CMMC and IEC 62443 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 setup with us.
We walk through the cipher suites, the micro-DMZ design and the CMMC evidence for your plants.
Talk to sales