An air-gapped network cannot reach an external certificate authority or pull down a Certificate Revocation List (CRL) from the internet. So how do you run OPC-UA with proper authentication when the entire Public Key Infrastructure (PKI) must live inside the gap? Most OPC-UA security documentation quietly assumes a plant that can phone home to a discovery server and an online CA. Strip that assumption away and the same security model still works, but every piece of the certificate lifecycle becomes something you run by hand.
Start with the part people get wrong most often: OPC-UA authenticates at two distinct layers, and confusing them is the most common source of misconfiguration. The protocol separates application authentication, which establishes trust between a client process and a server process, from user authentication, which establishes the identity of the human or service account behind a session. Both layers are defined in the OPC Foundation's security model. See OPC UA Part 2: Security Model for the normative description of how these layers interact, including the threat model the standard was built to counter.
Layer One: Application Authentication With Instance Certificates
Every conforming OPC-UA application, whether client or server, holds an Application Instance Certificate. This is an X.509 certificate that binds a public key to a specific software instance, identified by its ApplicationUri. When a client opens a SecureChannel to a server, the two applications exchange certificates and each decides whether to trust the other. This decision is not made by querying an online directory. It is made locally, against a trust list.
A trust list is the on-disk set of certificates an application will accept, split into two stores. The trusted store holds either the peer leaf certificates you explicitly trust or the CA certificates whose issued certificates you trust by chain. The issuer store holds intermediate and root CA certificates needed only to complete chain validation, plus any CRLs. The mechanics of this validation, and the structure of the trust list itself, are specified in OPC UA Part 6: Mappings, which defines the file formats and the certificate validation steps a stack must perform before accepting a channel.
In a connected deployment, a Global Discovery Server (GDS) automates trust-list distribution and certificate enrollment across the plant. In an air-gapped deployment, there is no reachable GDS, so trust-list management becomes a deliberate, manual operation. This is the central architectural difference, and the rest of this post follows from it.
Layer Two: User Authentication and Identity Tokens
Once two applications trust each other and a SecureChannel exists, the client opens a Session and presents a user identity token. OPC-UA defines three token types in ascending order of assurance:
- Anonymous: no user identity is asserted. The session inherits only whatever access the server grants to unauthenticated callers. Acceptable only for read-only, non-sensitive data, and best disabled entirely in production.
- Username/Password: the client sends a username and a password encrypted with the server's public key. This is straightforward but inherits all the operational weaknesses of shared secrets, namely rotation, storage, and the risk of credential reuse across systems.
- X.509 Certificate: the user presents a certificate and proves possession of the private key. This gives you per-user cryptographic identity, revocability, and a clean audit trail, at the cost of having to manage a second certificate population alongside your application certificates.
The critical point for air-gapped design is that these two layers are independent. You can run SignAndEncrypt application security with Anonymous user tokens, or unsecured application transport with username tokens, and both are misconfigurations. Strong authentication means securing both layers together: trusted application certificates establishing an encrypted channel, then a non-anonymous user token establishing accountability on top of it.
Security Policies and SignAndEncrypt
The protection applied to the SecureChannel itself is governed by the MessageSecurityMode and the chosen SecurityPolicy. There are three security modes: None, Sign, and SignAndEncrypt. None provides no protection and should never be used outside a lab. Sign guarantees integrity and authenticity but leaves payloads readable on the wire. SignAndEncrypt guarantees integrity, authenticity, and confidentiality, and is the only mode appropriate for production OT traffic.
The SecurityPolicy selects the actual cryptographic suite. Older policies built on SHA-1 and RSA-15, such as Basic128Rsa15 and Basic256, are deprecated and should be disabled. Current deployments should require Aes256_Sha256_RsaPss or, where supported, the ECC-based policies. The full catalogue of policies and their cryptographic primitives is maintained in OPC UA Part 2: Security Model. Pinning servers to SignAndEncrypt with a modern policy, and explicitly rejecting None and the deprecated suites, closes the most common downgrade path an attacker would otherwise probe.
Certificate Management Without a Cloud GDS
This is where air-gapped deployments diverge sharply from the textbook. With no internet-reachable CA and no online GDS, the entire certificate lifecycle has to be designed as an offline workflow.
Run an Offline Certificate Authority
Stand up a dedicated, offline root CA inside the enclave, on hardware that never touches an external network. Keep the root key offline and used only to sign an intermediate issuing CA; the intermediate does the day-to-day issuance. This two-tier design limits exposure of the root key and lets you revoke and reissue the intermediate without rebuilding every endpoint. NIST's guidance on industrial control system security treats this kind of internally administered PKI, with documented key management, as a baseline control for isolated networks. See NIST SP 800-82 Rev. 3, Guide to Operational Technology Security.
Distribute Trust Lists by Hand
Because no GDS is reachable, trust lists are pushed manually. Export the CA certificate and the per-endpoint application certificates, transfer them across the air gap on controlled, scanned removable media following your media-handling procedure, and install them into each application's trusted and issuer stores. Treat this as a change-controlled operation with a recorded inventory of which certificate lives on which endpoint, because that inventory is the only map you will have during an incident.
Solve Revocation Offline
CRL distribution points and OCSP responders both assume reachable infrastructure, so neither works across an air gap by default. You have two realistic options. Either generate CRLs on the offline CA and distribute them on the same controlled media cadence as trust lists, accepting that revocation latency equals your distribution interval, or, for the strongest posture, treat the trust list itself as the authority: remove a compromised certificate from every trusted store directly. NIST SP 800-82 and the broader NIST SP 800-57 key management guidance both stress that a revocation process must exist and be tested, not just designed, before the PKI is relied upon.
Plan Renewal Around Maintenance Windows
Certificates expire, and an expired application certificate will silently break a SecureChannel. Track every certificate's validity window centrally, schedule rotation ahead of expiry, and rehearse the rotation during a planned maintenance window rather than discovering the dependency during production. Offline renewal is a manual reissue-and-redistribute cycle, so it needs lead time built into the maintenance calendar.
Putting the Layers Together
A defensible air-gapped OPC-UA deployment looks like this in practice. Servers require MessageSecurityMode SignAndEncrypt with a modern SecurityPolicy and reject everything weaker. Application instance certificates are issued by the offline intermediate CA and present on both ends, with trust lists holding only the certificates that belong there. The Anonymous user token is disabled, and sessions authenticate with username or, preferably, X.509 user certificates so that every action ties back to an identity. Revocation and renewal run on a documented offline cadence with a tested process behind them.
Overcoming Common Challenges
Legacy Systems
Older endpoints may only support deprecated policies or no message security at all. Rather than weaken the whole plant to accommodate them, place these devices behind a gateway that terminates a secure channel on their behalf, or inside a tightly scoped enclave that limits who can reach them. The goal is to contain the weak link, not to lower the bar for everything else.
Compliance and Standards
Internally administered PKI, documented key management, and a tested revocation process map directly onto the controls expected by frameworks such as NIS2 and CMMC, and onto the OT-specific guidance in NIST SP 800-82. Designing the offline lifecycle deliberately is also what makes a clean audit possible later.
Training and Awareness
Manual trust-list distribution and offline renewal are procedures, and procedures fail when the people running them do not understand why each step exists. Invest in the runbooks and the training that go with them, because in an air-gapped PKI the human process is the control.
Conclusion
In air-gapped environments, your offline certificate authority and your manual trust-list discipline are the single most critical security components. Get the offline CA's key management, the trust-list distribution procedure, the revocation path, and the renewal schedule right before deploying OPC-UA authentication across your plant. Pin every server to SignAndEncrypt with a modern policy, disable anonymous access, and authenticate users with certificates wherever you can. Test certificate rotation during a maintenance window, not during production. Once the offline PKI is solid, OPC-UA's built-in security model is fully usable with no internet connectivity at all.
