Join Keyfactor at RSA Conference™ 2024    |    May 6 – 9th    | Learn More

  • Home
  • Blog
  • How to Secure Your Enterprise’s Root Certificate Authority

How to Secure Your Enterprise’s Root Certificate Authority

Having the privilege to work with some of the best, if not the best PKI and security professionals in the field, I have learned the extreme importance of the practices used in securing the root certification authority (CA) platform. This includes software level security, hardware level security, and physical security.

By the same token, working on various projects and with many different clients, I’ve also had occasions to hear “fascinating” stories of how some companies take the security of their root CA lightly. No, the root CA should not be stored in someone’s desk just because the drawer is locked. That “old” server sitting in a rack, not plugged in to anything, cannot be decommissioned because “it’s not doing anything.”

For this blog entry, I would like to concentrate on physical security aspects surrounding the root CA.


The root CA is the most important piece in the PKI architecture. Everything downstream depends on its trustworthiness. If that piece is compromised, everything else is, in effect, also compromised. Needless to say, taking extreme security measures for access to the root CA is highly recommended.

If we look at the physical security, it is important to ask the following questions:

Where will the root CA and all of the cryptographic materials be stored?

Let’s focus on the facilities that will be used to store the root CA and all crypto material. How secure is that facility? Does it have 24/7/365 guards? Is all activity monitored? What is the security camera video retention period? Are proper checks in place for access to the facilities?

Who has the access to the facility? What is the SoD (Separation/Segregation of Duties) model?

No person should be able to gain access to the root CA alone, or go through any access points alone, to retrieve the root CA. SoD is extremely important, not only for obvious security reasons, but also for any necessary audit purposes.

A clear and solid SoD model must be developed, documented, and followed. Each individual must have assigned roles and tasks which they are responsible for.

How is facility access controlled and logged (the “gatekeeper”)?

This person is responsible for access control to the facilities. This also separates the duties between those who have physical access to the root CA and those who do not.

How is the root CA access logged?

Any access to the root CA must be logged. Access logs should be available for quick retrieval and should show relevant information such as the reason why the root CA was accessed, date, time, and personnel who accessed it. The level of log detail that the organization wishes to maintain is solely up to them. The suggested parameters are considered to be minimums.

How is the cryptographic material stored and secured?

It is obvious that the root CA and all of the cryptographic materials absolutely must be stored in a proper way. This is the PKI’s most prized possession and it should be treated as such. Is it going to be stored in a safe? A vault? It is important to keep in mind that it should to be stored in a way which would prevent access by a singular person.

Are proper Disaster Recovery (DR) and Business Continuity (BC) processes developed and tested?

Periodic DR and BC exercises should be performed to ensure a quick and efficient way to bring business operations back to normal in the case of a disruptive event. Proper access to the facilities and root CA should be reviewed. All of the documentation should be up to date, tested and understood by all of the stakeholders who would be involved in DR and BC efforts.

Of course, there are many other factors in protecting the root CA such as hardware security module (HSM) devices, how will they be deployed, architecture considerations, card quorums, etc. All of these methods are important, on top of physical security for your organization’s root CA.