There are at least two possible fixes for that situation:
1. Use HSMs
2. Do constant key rotation
But (2) doesn't work for several reasons and (1) does, which is why in practice people use HSMs.
It doesn't work because:
1. There is always a period for which a key is live, and if rogue employee can simply copy a private key on a USB stick they will probably abuse it quite soon after doing so. You're encoding into the infrastructure (at massive cost) the assumption that for some reason the attacker will wait a long-ish period of time before using their access and rotation will thus defeat them, but there's no reason to assume that. So it can easily end up useless.
2. If your key handling is so weak that someone can just walk off with the private key then they can probably tamper with the key generation process too.
It's obviously great if you can make key rotation easy, but in the cases I've been involved with it was always hard. There's got to be a root of trust somewhere so often making key rotation easy and fast just means pushing the trust to a different key that can't be easily rotated (e.g. firmware key).
HSMs aren't perfect. They're just specialized computers at the end of the day. But given a choice between building a better HSM, or trying to solve very thorny distributed computing problems that at minimum assume things like a globally synchronized clock, the former seems easier, much more likely to actually work and much less likely to create unforced outages.
Remember that in my post I'm discussing not only the relatively easy case of well maintained always-online laptops and servers running software built by well funded tech firms and getting certificates from Google-subsidized free CAs. I'm also considering all the other uses of expiring keys/certs, like in private networks, credit card chip systems, industrial control, phone networks, internal cloud usages etc.
A (potential) key compromise can result from more things than an employee leaving. It can also be due to, say, an algorithm change. HSMs do not solve this (and in fact probably make it harder to change the encryption algorithm).
Why do HSMs make it harder? Algorithm changes are rare, and when they happen you'd need to upgrade all the clients that are working with the keys or certificates, so at that point it's a question of software rotation rather than key rotation. The HSM shouldn't be your biggest problem at that point.
1. Use HSMs
2. Do constant key rotation
But (2) doesn't work for several reasons and (1) does, which is why in practice people use HSMs.
It doesn't work because:
1. There is always a period for which a key is live, and if rogue employee can simply copy a private key on a USB stick they will probably abuse it quite soon after doing so. You're encoding into the infrastructure (at massive cost) the assumption that for some reason the attacker will wait a long-ish period of time before using their access and rotation will thus defeat them, but there's no reason to assume that. So it can easily end up useless.
2. If your key handling is so weak that someone can just walk off with the private key then they can probably tamper with the key generation process too.
It's obviously great if you can make key rotation easy, but in the cases I've been involved with it was always hard. There's got to be a root of trust somewhere so often making key rotation easy and fast just means pushing the trust to a different key that can't be easily rotated (e.g. firmware key).
HSMs aren't perfect. They're just specialized computers at the end of the day. But given a choice between building a better HSM, or trying to solve very thorny distributed computing problems that at minimum assume things like a globally synchronized clock, the former seems easier, much more likely to actually work and much less likely to create unforced outages.
Remember that in my post I'm discussing not only the relatively easy case of well maintained always-online laptops and servers running software built by well funded tech firms and getting certificates from Google-subsidized free CAs. I'm also considering all the other uses of expiring keys/certs, like in private networks, credit card chip systems, industrial control, phone networks, internal cloud usages etc.