Most industrial gear ships a web interface — a PLC's built-in HMI, a drive's configuration page, a building-management dashboard. Many of them speak plaintext HTTP on port 80, 8080, or similar, with no real authentication. Access Gate puts identity and encryption in front of them without touching the device.
What You Get
When you publish an HTTP or HTTPS asset through an enclave, the gate can:
- Authenticate the user first via an access screen before the web app is ever reachable — or pass the connection straight through when a login isn't needed.
- Wrap plaintext HTTP in TLS so credentials and session cookies no longer cross the network in the clear: the browser talks HTTPS to the gate, the gate talks the device's native HTTP on the protected side. See Set up TLS encryption.
- Scope access by ACL — only the users, groups, or roles you allow reach the page, and only over the protocol you grant.
Set It Up
- Add the asset to an enclave — see Protecting an asset with enclaves.
- In Enclaves → [Your Enclave] → Access Control, add an
allowrule. - Pick the principal (user, IdP group, or role) and the asset(s), then save.
- Point users at the asset's URL or its overlay IP.
Notes & Gotchas
- Mixed-content pages. Some embedded HMIs hardcode
http://<ip>links or load assets over absolute URLs. A useful pattern: you can use Access Gate to add a layer of identity and encryption in front of an app that only speaks plaintext. This is achieved via access screens and TLS encryption.
Protecting HTTP server with TLS via Access Gate - Self-signed device certs. If the device already serves HTTPS with a self-signed certificate, the gate connects to it on the protected side; users still see the gate's trusted certificate, not the device's.