The countdown is on to Keyfactor Tech Days     | Secure your spot today!

  • Home
  • Blog
  • PKI
  • [CTO Interview] The Enterprise Movement to PKI as-a-Service

[CTO Interview] The Enterprise Movement to PKI as-a-Service

PKI

Keeping up with a secure, scalable, and well-run public key infrastructure (PKI) is no easy task. That’s why many enterprises are starting to rethink their legacy PKI and switch to an enterprise PKI as-a-Service.

I recently got the chance to sit down with Dr. Ed Amoroso, the Principal Analyst, and CEO of TAG Cyber, to discuss the PKI resurgence in enterprise and IoT use cases.

Watch my entire video and read parts of the transcript below.

 

Why is there this movement to PKI as-a-Service in the enterprise?

We started doing PKI as-a-Service about eight years ago, which was right around when we launched our software platform. Both the “as-a-Service” offering and certificate management came out of the unmet needs that we saw in our customer base.

Although you can buy digital, x.509 certificates from the public providers, most organizations also need privately rooted PKI for Wi-Fi, web services, and internal devices. This means enterprises can’t keep a well-run, well-architected, and scalable PKI by “setting and forgetting” their enterprise PKI.

Are enterprises transparent about their cryptography management challenges?

Sometimes they have to be transparent because something terrible has happened. We have customers, before adopting PKI as-a-Service, that had misconfigured their PKI inadvertently.

For example, one customer they had set up on their own an internal PKI to encrypt laptops and desktops. Then they wound up outsourcing all of their IT, and in that transition, they lost all of the expertise around where all the keys were stored, how the archival worked. This led to literally 70,000+ laptops and desktops that they couldn’t decrypt.

Whether you’re running your own PKI or whether we’re doing it for you, the need to have a complete inventory of all the keys.

Help me understand how certificate lifecycle management works. Is this different from how people have done it in the past?

Well certificates are very similar to a driver’s license or a passport. In both of those cases, one of the similarities is that there is a predefined date of obsolescence.

In the case of a passport or driver’s license that’s for a variety of reasons. Perhaps your address has changed, or you’ve aged and you don’t look like the picture on your driver’s license anymore. This predefined renewal date leads to having to have a plan for how those things get updated.

With digital certificates, you really want to look at it holistically from the point of:

  • How do I issue the certificates?
  • How do I get them where they need to go?
  • When can they be used?
  • Who’s allowed to get them?
  • What logging and policies do I have around that?
  • Who’s allowed to revoke that certificate and have it ceased to be trusted?

And then of course, when the certificate starts to approach exploration, you need to know who’s going to be responsible for updating that certificate. And clearly there are products such, as Keyfactor, that can help with all of those parts of the lifecycle.

Automation plays a crucial role in that renewal lifecycle, and can help avoid downtime and outages.

It seems to me that there is a massive growth opportunity for PKI in securing IoT devices within the next ten years, is this accurate to say?

It is.

PKI has been around a long time but what’s happened lately is just this explosion of use cases, both in the enterprise, and certainly in IoT.

What we’re seeing in IoT, is this concept of things that have never had network stacks now being able to communicate. As soon as you have an ability to communicate, you need to be able to do things like authenticate.

How do I know that what I’m talking to is legitimate? How do I know that the information that I’m sending is secure? How do I know that a firmware update that I’m pushing out is legitimate? If you’re pushing a firmware update out to a pacemaker, or an insulin pump, you better make sure that those are authentic.

However, most organizations diving into IoT authentication don’t consider updateability in their device lifecycle.

The reason why certs expire isn’t to make people’s lives miserable. It’s because the algorithm’s age, the key’s age, they become insecure over time. And that is just also true for IoT devices.

It might be difficult to update a key on an IoT device, but this doesn’t absolve you from the fact that the crypto that it uses will become insecure in about five to ten years. We can predict that sort of thing because the algorithms that we were using five or ten years ago are not secure now.