A cryptographic key does not wear out, but the longer it stays in use the more chances there are for it to leak, and the more damage a leak does. Cryptographic key rotation is the practice of deliberately retiring keys and bringing in fresh ones on a schedule, so that no single key protects too much for too long. In OT this runs headlong into the reality of field assets that live for decades and cannot be casually taken offline, which makes rotating keys without an outage a genuine design problem. This guide explains what key rotation is, how graceful rollover with overlapping keys avoids downtime, how legacy pre-shared keys get rotated, and why crypto-agility matters over the long life of OT hardware.
Cryptographic Key Rotation in one line: Cryptographic key rotation is the periodic replacement of cryptographic keys with new ones so that any single key is used for a limited time and protects a limited amount of data. Rotating keys shrinks the window in which a leaked or aged key can be exploited and limits the damage if one is compromised. The main challenge in OT is doing it without interrupting service on long-lived field assets, which is handled through graceful rollover where old and new keys are both valid during a transition.
The case for rotation rests on exposure over time. Every use of a key, every place it is stored, every device it lives on, and every year it stays in service is another opportunity for it to be copied, guessed, or leaked, and the consequences of a leak grow with the amount of data and the number of connections that one key protects. Rotating the key on a schedule caps that exposure: if a key is only in use for a bounded period, then even if it is quietly stolen the attacker's window to exploit it closes when the key is retired, and everything protected after the rotation is out of their reach. Rotation is, in effect, a way of limiting the blast radius of a compromise you may not even know has happened.
It is worth separating this from certificate lifecycle management, which the two are easy to conflate. A certificate is a signed statement about a key; rotating certificates is about renewing those statements before they expire. Key rotation is about the key material itself, the actual secret doing the cryptographic work, which may be replaced on its own schedule for its own reasons even when certificates are handled separately. A key can be rotated because it is aging, because it was potentially exposed, or because policy demands periodic replacement, and the point of the exercise is always the same: keep any one secret from becoming a single, long-lived point of failure.
The hard part in OT is that you cannot simply swap a key and expect everything to keep working, because the two ends of a protected relationship have to agree on which key is in force at every instant. Flip one side to a new key before the other is ready and the connection breaks, which on a field asset can mean lost telemetry or a dropped control path. The answer is graceful rollover: introduce the new key while the old one is still valid, run a transition window during which both keys are accepted, migrate each relationship over to the new key, and only then retire the old one. Because there is never a moment when neither key works, the rotation happens underneath live operation without an outage.
This overlap is what makes rotation practical for assets that cannot be taken down. A device can begin honoring a new key while still accepting the old one, so its peers move across at their own pace rather than all at a single cutover instant, which matters when some of those peers are on intermittent links and will not check in on cue. The trade-off is that during the overlap two keys are live at once, which is a slightly larger surface for that window, so the transition is kept as short as operations allow. Done well, the whole thing is invisible from the control room: data keeps flowing, connections stay up, and the underlying secret has quietly been replaced without anyone dispatching a truck or scheduling a maintenance outage.
Plenty of OT still runs protocols that authenticate with a pre-shared key, a single secret both ends already hold, rather than with certificates. Rotating a pre-shared key is conceptually the same overlap problem but is often clumsier in practice, because distributing a new shared secret to both ends of every relationship can mean touching devices individually, and some older equipment offers no graceful way to hold two keys at once. This is exactly where rotation on legacy assets gets expensive, and where operators have to weigh the cost of frequent rotation against the reality of the hardware they are stuck with. Where a protocol supports overlapping keys, rotation can be staged; where it does not, rotation may require a coordinated maintenance window, which raises the stakes on getting the timing right.
Standing behind all of this is crypto-agility, the ability to change not just keys but the algorithms and mechanisms underneath them over an asset's service life. OT hardware routinely stays in the field for decades, far longer than any given cryptographic choice remains state of the art, so a device installed today may need to move to different keys, longer keys, or different algorithms well before it is retired. Building rotation in from the start, and choosing devices and platforms that can accept new key material and adapt their cryptography without a forklift replacement, is what keeps a long-lived fleet from calcifying around a scheme that time renders weak. For a cloud SCADA platform such as Merobix, this matters because the platform is the point where a large, distributed fleet's connections converge, so being able to roll keys gracefully across that fleet, honoring old and new keys through each transition, is what lets security keep pace with the hardware without forcing operators to choose between staying current and staying online.
Because exposure accumulates over time: the longer a key is in use and the more it protects, the greater the chance it leaks and the greater the damage if it does. Rotating on a schedule caps that exposure, so even a key stolen without your knowledge only helps an attacker until it is retired, and everything protected afterward is out of reach. Rotation limits the blast radius of a compromise you might never detect.
Through graceful rollover with overlapping validity: the new key is introduced while the old one is still accepted, both work during a transition window, each relationship migrates to the new key, and only then is the old key retired. Because there is never a moment when neither key is valid, the rotation happens underneath live operation. The overlap also lets peers on intermittent links move across at their own pace rather than at a single cutover instant.
Certificate renewal is about refreshing the signed statements that vouch for a key before they expire, while key rotation is about replacing the underlying key material itself. A key can be rotated on its own schedule and for its own reasons, such as aging or possible exposure, even when certificates are managed separately. The two are related but distinct: one governs the certificates, the other governs the actual secrets doing the cryptographic work.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.