For a long time, the factory network was its own little world. Machines talked to their controllers, and the connection to the office was a single, carefully guarded gateway. That world is gone: machine data flows into dashboards, ERP systems and the cloud, suppliers maintain systems remotely, and new sensors are added every month.
Every new connection is useful — and a possible way in. This article explains why encryption alone does not make a factory secure, what certificates have to do with it and why rotating them regularly is one of the most effective and most neglected measures.
Why OT security is different from IT security
In the office, systems are updated every month and restarted overnight. In production, that is often not possible:
- Long lifetimes: Machines and controllers run for fifteen or twenty years — far longer than any operating system is supported.
- No downtime: Updates and restarts mean production stops. They are planned months in advance, if at all.
- Old protocols: Many devices communicate unencrypted and cannot check who they are talking to.
- Flat networks: Once inside, an attacker can often reach every device, because the network was never divided into zones.
That is why OT security cannot rely on every device protecting itself. Protection has to come from the network around the devices.
Encryption needs identity
Encryption ensures that nobody can read or change data along the way. But it only helps if you also know who is on the other end. Otherwise, an attacker simply sets up an encrypted connection of their own.
This is what certificates are for. A certificate is a digital identity card: it proves that a device or service really is who it claims to be. With mutual TLS (mTLS), both sides show their certificate, and only known, whitelisted devices are let through. OPC UA uses the same principle with its own application certificates.
In short: encryption protects the content, certificates protect against the wrong partner. A secure factory network needs both.
The underrated problem: certificates that never change
In many plants, certificates are issued once and then forgotten. That causes three problems:
- Stolen identities stay valid: If a certificate and its key are copied, the attacker can use them for as long as the certificate is valid — often for years.
- Shared certificates spread the damage: If several devices or sites use the same certificate, one compromised device opens the door for all of them.
- Expiry causes outages: When a certificate that nobody is watching expires, connections suddenly stop — and production with them.
That is why security standards such as IEC 62443 and, in the EU, the NIS2 directive expect certificates and keys to be managed and renewed regularly. Doing this by hand for hundreds of connections is hardly realistic — so in practice, it often doesn't happen.
What a workable approach looks like
Instead of upgrading every machine, you protect the traffic where it crosses into the factory or between areas:
- An encrypting proxy at the boundary: A proxy in the factory encrypts and decrypts all traffic passing through it. Old devices keep working unchanged.
- Separate certificates per connection type: Machine data, remote maintenance and the ERP connection each get their own certificates, so a problem in one does not affect the others.
- Whitelisting: Only devices that are explicitly allowed get through. Everything else is rejected.
- Automatic rotation: Certificates are renewed automatically at a set interval — without anyone having to remember.
- No shared certificates: Each proxy and each site has its own certificates, so a compromise stays isolated.
How RALUS CertProxy puts this into practice
We developed RALUS CertProxy for exactly this approach. It runs on a server in your factory or on-premises and encrypts and decrypts all traffic that passes through it. Each type of communication uses its own certificates from a managed pool, and only whitelisted devices get through.
CertProxy supports every common type of certificate, including certificates from public and private certificate authorities, self-signed certificates, OPC UA certificates, mTLS client certificates and IEEE 802.1AR device certificates. Certificates rotate automatically at the interval you set, so IT meets its rotation standards without manual work.
Several CertProxies work together: they rotate certificates randomly, without repeats and without any certificate being shared between proxies. Whether the IT network or one factory is compromised, CertProxy keeps the factory isolated.
Where to start
- 1List the connections: Which systems talk to the factory network, and which protocols do they use? A simple list is enough to start.
- 2Rank them by risk: Remote maintenance and cloud connections usually come first, followed by connections between sites.
- 3Protect one connection first: Start with the most critical connection, check that it runs reliably, then continue step by step.
- 4Set a rotation interval: Agree with IT how often certificates must be renewed, and let it happen automatically.
- 5Monitor: Keep an eye on connections and certificates, so nothing expires or changes unnoticed.
Conclusion
A connected factory needs more than a firewall at the edge. Encryption, clear identities and certificates that are renewed regularly make the difference between a network that is merely encrypted and one that is truly protected — and none of it needs to mean more manual work.
Want to know which of your connections to protect first? Request a CertProxy demo.