Trusting a certificate authority means trusting any certificate that authority signs. Usually that is what you want, but it also means that if an attacker ever gets a certificate signed by a trusted CA, or subverts the CA itself, they can impersonate a server you rely on and your device will accept it. Certificate pinning removes that latitude by telling a device to trust one exact certificate or key and nothing else, even from an otherwise-trusted CA. This guide explains how pinning works on OT devices, why it is a strong defense against man-in-the-middle attacks, and the operational brittleness it introduces when certificates need to rotate.
Certificate Pinning in one line: Certificate pinning is a technique where a device is configured to accept only one specific certificate or public key for a given server, rather than any certificate a trusted CA has signed. The expected certificate or key, the pin, is stored on the device, and any connection presenting a different certificate is refused even if it is validly signed. This blocks man-in-the-middle attacks that rely on a fraudulent but CA-trusted certificate, at the cost of extra care whenever the legitimate certificate has to change.
Normal certificate validation is permissive by design: a device accepts any certificate that chains to a trusted authority and matches the identity it expects. Pinning deliberately narrows that. Instead of trusting a whole authority and everything it signs, the device is told to expect one particular certificate, or one particular public key, for a specific server, and to reject anything else. The pin can be the exact certificate or, more flexibly, the server's public key, which survives a routine certificate reissue as long as the underlying key stays the same. Either way, the device now makes a much stricter check: not just was this signed by someone I trust, but is this the exact identity I was told to expect.
The distinction between pinning a certificate and pinning a public key matters in practice. A certificate pin ties trust to that specific certificate, so any reissue, even one that keeps the same key, breaks the pin and must be accompanied by an update to the device. A public-key pin ties trust to the key pair, which is looser and lets the certificate be reissued around the same key without touching the pin, while still rejecting any certificate built on a different key. Both are stricter than default CA validation, and both put the decision about what to trust into an explicit value stored on the device rather than delegating it wholesale to the authority.
The threat pinning is built to counter is a man-in-the-middle who possesses a certificate that a device would normally accept. This can happen in more ways than operators like to admit: a CA can be tricked or compromised into issuing a certificate for a name it should not, a device's trust store can be seeded with an attacker-controlled authority, or an interception appliance can present certificates signed by a CA the device trusts. In all of these, ordinary validation passes, because the fraudulent certificate really is signed by a trusted authority, and the device connects to the attacker believing it reached the genuine server. The attacker then sits in the middle, reading and potentially altering everything that passes.
Pinning defeats this because the attacker's certificate, however validly signed, is not the pinned one. The device is not asking whether some trusted CA signed the certificate; it is asking whether this is the specific certificate or key it was told to expect, and the interceptor cannot produce that without also stealing the server's actual private key. In OT this is a meaningful protection for the fixed, long-lived relationships that dominate the environment: an HMI that always talks to one historian, a gateway that always reports to one endpoint, a controller that always connects to one server. Because those pairings do not change often, pinning the expected identity closes off an entire class of interception that CA-based trust alone would let through.
Pinning's strength is also its weakness. By hard-coding trust in one exact identity, a pin turns any legitimate change to that identity into a coordinated update problem. If a server's certificate has to be replaced, because it expired, because the key was rotated after a scare, or because the infrastructure changed, every device pinned to the old value will refuse the new certificate until its pin is updated. Handle that poorly and a routine certificate rotation becomes a self-inflicted outage, with pinned devices cut off from the very server they are supposed to trust. This brittleness is the reason pinning is applied selectively rather than everywhere, and why public-key pinning, which survives certificate reissue on the same key, is often preferred over pinning the certificate itself.
The way to keep pinning safe is to treat pin updates as part of the same lifecycle discipline that governs certificates generally, and to build in overlap: distribute the new pin to devices before the old certificate is retired, so there is a window where both are accepted and no device is stranded. In OT the calculus favors pinning precisely where relationships are stable and the anti-interception benefit is worth the extra coordination, and it favors caution where certificates rotate frequently or where devices are hard to reach for updates. For a cloud SCADA platform, where a fleet of devices all connect to a common set of endpoints, pinning has to be weighed against the operational reality that those endpoints and their certificates will occasionally change, so any pinning strategy must be paired with a reliable way to push updated pins to the field before old certificates fall away. Used with that discipline, pinning is a sharp tool against interception; used carelessly, it is a reliable way to lock yourself out.
Certificate pinning ties trust to one specific certificate, so any reissue, even one keeping the same key, breaks the pin and requires updating the device. Public key pinning ties trust to the underlying key pair, so the certificate can be reissued around the same key without breaking the pin, while still rejecting any certificate built on a different key. Public key pinning is generally more resilient to routine certificate changes, which is why it is often preferred.
Ordinary validation only asks whether a trusted authority signed the certificate, so a fraudulent but validly signed certificate, from a compromised CA or a rogue authority in the trust store, passes and the device connects to the attacker. Pinning instead asks whether this is the exact certificate or key it was told to expect. The interceptor cannot produce the pinned identity without the server's real private key, so the connection is refused even though the certificate is technically valid.
Its brittleness during rotation. Because the device trusts one exact identity, any legitimate change to that certificate or key breaks the pin, and every pinned device refuses the new certificate until its pin is updated. Handled poorly, a routine certificate rotation becomes a self-inflicted outage. The mitigation is to update pins as part of certificate lifecycle discipline and to overlap the old and new values so no device is ever stranded.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.