Identifying and Mitigating PKI Assessment Risks

Your PKI design and certificate policy have an impact on the security of your network and devices as a whole. You should design and implement your PKI to fend off typical dangers, much as you would guarantee your home has an earthquake-resistant foundation or a hurricane-resistant roof.

Many of these choices must be made in advance, during the design and development of your software or product. Although it takes work to implement the required security measures in your PKI, taking the necessary precautions will help you reduce security concerns in the future.

Think about this, What risk to your security would a compromised certificate on your network? Could a server be accessed using the certificate’s authentication? Could it be used against your users in a man-in-the-middle attack?

When creating a programme or device that makes use of certificates for authentication or secure communications, these queries should be carefully considered. Technical choices must be made regarding how your product will handle certificates and how your PKI will be designed and managed.

This article is intended for designers and producers who work with private-trust client or device certificates, such as those found in software or Internet of Things (IoT) devices.

Quick Answer: What Are PKI Assessment Risks?

PKI assessment risks are the design and operational gaps in certificate validity periods, private key protection, and revocation that let an attacker misuse a compromised certificate. Assessing them means checking how long certificates stay valid, whether private keys sit in a TPM, HSM, or encrypted store instead of plaintext, and whether CRL or OCSP revocation actually works end to end.

Last updated: August 2026 · Last verified: August 2026 · Recommended refresh cadence: quarterly, since certificate validity guidance, algorithm deprecation timelines, and CA/Browser Forum requirements change on a similar schedule.

Executive Summary: Key Takeaways

• Three risks, one system: certificate validity, private key protection, and revocation only work as a set; weakening one undermines the other two.
• Long validity periods raise the stakes: longer-lived certificates create more targets for attackers and demand a more capable revocation system.
• Plaintext keys are the most common failure: a private key stored without hardware or encrypted protection can be extracted and used to impersonate a device or decrypt traffic.
• Revocation doesn’t require constant connectivity: cached CRLs and OCSP stapling both support devices with limited or intermittent internet access.
• Algorithm deprecation is a scheduling problem: SHA-1 and short RSA keys were secure once; the SHAttered collision (February 23, 2017) proved theoretical weaknesses eventually become practical.

Who Should Care About PKI Assessment Risks

These risks show up in design decisions long before an incident does. Here is what each role should own.

PKI Administrators

Own the day-to-day certificate validity, key storage, and revocation configuration, and keep the certificate inventory current enough to run a risk assessment on demand.

Security Architects

Design the risk controls into the PKI before launch: validity periods, key storage hardware, and revocation mechanism, rather than retrofitting them after a product ships.

Platform Teams

Implement key storage and revocation checking in the actual product or device, including CRL caching or OCSP stapling for intermittently connected hardware.

Compliance Teams

Map validity, key protection, and revocation controls to the relevant framework (ISO/IEC 27001, PCI DSS, WebTrust/ETSI) and confirm audit evidence exists for each.

CISOs

Own the residual risk decision: how long certificates stay valid, how well keys are protected, and how fast a compromised certificate can actually be revoked across the fleet.

Why This Matters: Data and Deadlines

According to DigiCert’s Trust Pulse survey (published July 2, 2025), nearly half of enterprises experienced a certificate-related outage in the past year, and 18.5% of affected organizations reported losses over $250,000. Unassessed PKI risk, an over-long validity period, an unprotected key, or a revocation system that was never tested, is exactly what turns a single compromised certificate into an outage of that size.

The CA/Browser Forum’s Ballot SC-081v3 (approved April 11, 2025) locks in shrinking TLS certificate validity: 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. Every validity-period risk assessment needs to account for this schedule now, since a certificate policy written around a 398-day maximum will already be out of compliance by 2026.

On the algorithm side, NIST finalized its first three post-quantum standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), on August 13, 2024. The SHA-1 deprecation this article uses as its example is not a one-time event: it is the same crypto-agility problem organizations will face again as PQC-capable certificates become mandatory.

PKI Risk Matrix

Use this matrix to score and document the three risk areas this article covers, plus two related risks that show up in the same assessment.

Risk	Likelihood	Impact	Detection Method	Mitigation	Control Mapping	Evidence
Certificate validity period too long	Medium	High	Certificate inventory audit; validity/expiration report	Shorten validity periods; align with the CA/Browser Forum schedule; automate renewal	NIST SP 800-57 key-usage guidance; CA/Browser Forum Baseline Requirements	Certificate inventory export showing validity periods and issuance dates
Private key stored in plaintext or unprotected	High	Critical	Key storage audit; device/firmware inspection; penetration test	Move keys into a TPM, HSM, or encrypted key store; never ship keys in plaintext firmware	ISO/IEC 27001 A.8.24 (cryptographic key management); NIST SP 800-57	Key storage configuration review; HSM/TPM attestation logs
No functional revocation mechanism	High	Critical	Revocation-checking test against a known-revoked certificate; CRL/OCSP endpoint test	Implement CRL and/or OCSP, with OCSP stapling where connectivity allows; test revocation end to end	RFC 5280 (CRL); RFC 6960 (OCSP); ISO/IEC 27001 A.8.24	Revocation test logs; CRL/OCSP endpoint uptime records
Deprecated algorithm still in use (e.g., SHA-1, RSA-1024)	Medium	Critical	Cryptographic algorithm inventory; CBOM scan	Migrate to current algorithms (SHA-256+, RSA-2048+/ECC); track a crypto-agility roadmap toward PQC	NIST SP 800-131A algorithm transitions; FIPS 186-5	CBOM/crypto inventory report; algorithm usage audit
CRL/OCSP endpoint unreachable or stale	Medium	High	Endpoint monitoring; CRL NextUpdate check	Monitor endpoint uptime; cache CRLs appropriately for intermittently connected devices; alert on stale CRLs	RFC 5280; internal Certificate Policy/CPS	Uptime monitoring dashboard; CRL freshness report
No documented certificate policy or CP/CPS	Medium	Medium	Policy document review; gap assessment	Draft and maintain a Certificate Policy/Certification Practice Statement covering validity, key protection, and revocation	WebTrust/ETSI EN 319 411 CP/CPS requirements; ISO/IEC 27001 A.5.31	Approved CP/CPS document; version history

Compliance Mapping

Risk Area	Relevant Framework / Control	What Auditors Look For
Certificate validity and lifecycle	NIST SP 800-57, CA/Browser Forum Baseline Requirements, ISO/IEC 27001 A.8.24	Documented validity periods, renewal automation evidence
Private key protection	FIPS 140-3, ISO/IEC 27001 A.8.24, PCI DSS Requirement 3	HSM/TPM validation certificates, key storage architecture diagrams
Revocation	RFC 5280, RFC 6960, ISO/IEC 27001 A.8.24	Revocation test results, CRL/OCSP availability SLAs
Crypto-agility and algorithm currency	NIST SP 800-131A, NIST PQC standards (FIPS 203/204/205)	Algorithm inventory (CBOM), migration roadmap
Governance and certificate policy	WebTrust, ETSI EN 319 411	Approved policy documents, review cadence records

Creating a PKI with Long-Lasting Security

We frequently converse with developers who are unaware of their alternatives for creating PKI and certificate policies. You have a lot of flexibility with private-trust PKI when it comes to your client and device certificates, enabling you to increase the security of your program or device.

We’ll go into detail about three crucial factors you should take into account to improve your PKI. Choosing certificate validity periods and replacement, safeguarding private keys, and utilizing certificate revocation—as well as how to use these controls effectively to reduce risk—are the first three topics.

Although certificates offer authentication and encryption, using them is not as straightforward as just installing them and calling it a day. Both of these qualities can be jeopardized, but with right mitigations they can also be strengthened.

The simplest solution could be to set up a shoddy PKI and never worry about managing your certificates, but this comes with security risks you might not have thought about.

Let’s use the recent deprecation of SHA-1 as an illustration. Researchers were aware of the weakness of the SHA-1 hashing method, which was designed to give cryptographic signatures to uniquely identify certificates. Last year, Google showed two distinct files with the same hash in a real-world collision.

The SHA-1 algorithm was effectively killed out by this collision, and many certificates were changed with the more secure SHA-2 algorithm to maintain security. Long-lived certificates were also included, which would become more exposed as time went on (computing power increases make it easier to exploit). Even if a SHA-1 collision would seem impossible right now, what about in 5 years? 20 years? These are crucial factors to take into account if your products will be used over an extended period of time.

The complexity of PKI security is quickly demonstrated by this straightforward example. You would need a technique to reissue and replace certificates on your devices, a revocation mechanism to deal with certificates you know were compromised, and the assurance that your network and users are no longer exposed to reduce the security hazards of a flawed hashing algorithm.

Validity of a Certificate

In the SSL/TLS realm, compromised technologies are an unavoidable issue. The protocol’s fundamental cryptographic technologies are built with a deprecation date in mind since we anticipate that stronger computers in the future may eventually compromise their security.

Major changes have occurred over the past ten years, such as the abandonment of the MD5 and SHA-1 hashing algorithms and the switch to 2048 bit. We’ll eventually run out of 2048-bit keys and have to replace them. It will be much easier to deal with these changes if you have a plan in place.

You must weigh the benefits of a long-lasting certificate against the difficulty of safeguarding long-lasting keys when determining the validity time for your certifications. Protecting these keys becomes more difficult over time as encryption standards deteriorate, are replaced, and as your collection of certificates expands. A flawed algorithm may eventually necessitate the urgent replacement of certificates for sustained security, as in the case of our SHA-1 example.

It’s important to think about both the expiration date and the process for replacing your certifications. Most of the time, we’ve discovered that trying to use a single certificate throughout the device’s lifetime involves too many security trade-offs.

You establish a wider variety of certificates (and accompanying private keys) that need to be kept secure by selecting longer validity periods. Because it grants them access for extended periods of time, this expands the number of targets for attackers and motivates them to compromise a certificate. This in turn makes having a revocation system more crucial and necessitates keeping revocation data on hand for longer periods of time, resulting in bigger revocation files and greater network activity.

However, creating a secure PKI does not require that certificates be changed every year. Long-lived certs can still be used while making effective plans for these changes. When you replace and renew device certificates, you can select the validity term that works best for you without being concerned that you’ll need to replace them in the future.

Keeping Private Keys Safe

Key compromise shares many of the same security factors as certificate validity. Attackers can mimic a device, decrypt and read data, and authenticate to a network if they can obtain a private key.

Keys must be safeguarded against compromise, revoked, and replaced if they are ever compromised if you wish to offer real authentication and encryption. This means that putting keys on a device in plain text, where they could be easily extracted, is not a good idea. Instead, think about a hardware defense like a secure chip (TPM) or a software solution like an encrypted key store, which offers real defense against attackers.

Even if you think your keys are suitably safeguarded, it’s crucial to have a functional revocation scheme. Attackers may become interested in finding a means to circumvent your security measures if they discover there is no practical way to stop them when they steal a key. An additional line of defence called revocation serves to neutralise and dissuade intruders.

These barriers have a lot in common. A dependable revocation system—one that can handle a high rate of revocations—becomes more crucial and expensive if your keys are simple to compromise.

Revocation

Because certificate revocation is a “high-cost” service that necessitates an active internet connection and high availability, several manufacturers and developers think they can’t support it. That is not the situation. You can check revocation information using industry-standard technology without connecting to a server or using the internet at all.

CRL (Certificate Revocation Lists) and OCSP are two technologies that are widely used in the business for verifying revocation information (Online Certificate Status Protocol). A CRL is comparable to a blacklist of serial numbers for certificates for individuals who are unfamiliar with these systems. With OCSP, the client sends a request across the internet to a central service to learn the status of a certain certificate’s revocation—much like calling an API. The X.509 certificate protocol includes both the CRL and OCSP protocols.

The more straightforward option, CRL, gives you flexibility in situations where your device might not have a dependable or quick internet connection. Traditionally, the issuing CA signs a CRL file every day, which the client can access online. However, the CRL can be cached and stored in circumstances where the device cannot quickly or routinely connect to the internet.

CRLs are signed and have a validity period, just like certificates. CRLs are reliable because they are signed by the CA. A CRL does not have to be sent from the CA directly to the device. Instead, they can be dispersed via a network, such as an internal network or a centralised cloud server. This has a benefit over a straightforward blacklist or whitelist. If a CRL file has a valid signature, you can download it from any location without worrying about manipulation.

When a CRL expires, which can be set for weeks or more, it can be cached on a device and used until then. Because of this, it’s a suitable choice for devices with spotty or erratic internet connections. This enables you to keep the advantages of revocation checking in many situations without incurring the technical expenses of repeatedly getting new data.

As long as the devices have access to a gateway or server that does, OCSP can also be used when the devices themselves do not have internet connectivity. The revocation information can be transmitted during the TLS handshake thanks to an optional OCSP feature called “stapling,” which enhances network performance. Both OCSP and CRLs can be implemented, with the most current CRL serving as a backup.

The fact that a commercial CA will already support one of these standard approaches is a benefit of employing it. They are flexible standards that may be customised to meet your unique needs because they support a wide range of possibilities.

Incident Examples

Two real incidents show what happens when these risks go unmanaged.

• SHAttered SHA-1 collision (February 23, 2017): Google and the CWI Amsterdam research institute produced two distinct PDF files that shared an identical SHA-1 hash, turning a theoretical weakness into a demonstrated, practical break. The industry accelerated its move to SHA-256, and any organization still using SHA-1 signed certificates today is carrying a risk that has already been proven exploitable.
• DigiNotar CA compromise (2011): attackers breached the Dutch certificate authority DigiNotar and issued hundreds of fraudulent certificates, including for major domains. Because DigiNotar’s detection and revocation response were too slow, browsers ultimately revoked all trust in the CA itself, an outcome that shows what happens when key protection and revocation infrastructure both fail at the same time.

Audit Evidence Table

Risk Area	Evidence an Auditor Should Request	Where It Typically Lives
Certificate validity	Certificate inventory with issuance and expiration dates	Certificate lifecycle management platform or CA export
Private key protection	HSM/TPM attestation, key storage architecture documentation	Security architecture repository, vendor attestation letters
Revocation	Revocation test logs, CRL/OCSP endpoint uptime records	Monitoring platform, incident response records
Algorithm currency	Cryptographic algorithm inventory (CBOM)	CBOM Secure or equivalent crypto inventory tool
Certificate policy governance	Approved CP/CPS document with version history	Compliance document repository

Remediation Checklist

• Inventory every certificate and its validity period; flag anything issued longer than current CA/Browser Forum guidance supports.
• Confirm private keys are stored in a TPM, HSM, or encrypted key store, never in plaintext firmware or configuration files.
• Test revocation end to end: revoke a test certificate and confirm dependent clients reject it via CRL or OCSP.
• Run a cryptographic algorithm inventory (CBOM) and flag any certificates still using SHA-1, MD5, or RSA keys under 2048 bits.
• Document a Certificate Policy/CPS covering validity periods, key protection, and revocation, and review it at least annually.
• Set monitoring and alerts on CRL/OCSP endpoint uptime and CRL freshness.

Certificate Lifecycle Management and PKI Modernization

Validity, key protection, and revocation are certificate lifecycle management questions at their core: validity periods govern renewal cadence, key protection governs how securely each certificate’s private key survives issuance to expiration, and revocation governs how the lifecycle ends early when something goes wrong. CertSecure Manager automates certificate lifecycle management, including certificate automation for renewal and revocation checking, so these three risks don’t depend on a manual spreadsheet. Organizations designing PKI for new products or IoT fleets should also evaluate PKI-as-a-Service for PKI modernization with these controls built in from the start.

Because algorithm deprecation (this article’s SHA-1 example) is a recurring problem, build a broader crypto agility plan alongside this risk assessment: the PQC Center of Excellence offers hands-on post-quantum testing, and a PQC readiness assessment can identify which certificates and keys will need replacing next. Pair both with CBOM Secure for ongoing certificate discovery and machine identity inventory, so the next algorithm transition starts from documented data instead of a fresh manual audit.

For more on the surrounding lifecycle, see What Are the Stages in a Certificate Lifecycle? and How to Avoid Certificate Outages.

Measuring Success and Ongoing Audits

Success looks like every certificate’s validity period matching current algorithm and CA/Browser Forum guidance, zero private keys stored without hardware or encrypted protection, a revocation test that passes end to end, and a documented Certificate Policy reviewed at least annually.

Refresh the certificate and algorithm inventory, the revocation endpoint monitoring configuration, and this risk matrix itself on a quarterly cadence, since validity-period rules, deprecated-algorithm timelines, and CA/Browser Forum requirements all shift on a similar schedule.

Conclusion

Frequently Asked Questions

What is the main takeaway from Identifying and Mitigating PKI Assessment Risks?

The main takeaway is that PKI risk comes from three interlocking decisions, certificate validity periods, private key protection, and revocation, and weakening any one of them undermines the other two. A fast revocation system means little if keys sit in plaintext, and well-protected keys still leave you exposed without a working way to revoke a compromised certificate.

Why does this matter for enterprise PKI teams?

Enterprise PKI teams often inherit certificate and key management decisions made early in a product or system’s design, so identifying these risks after deployment is far more expensive than designing around them up front. A single weak decision, like an unprotected private key or a validity period that outlives the algorithm backing it, can compromise every device or service built on that PKI.

What risks increase if this topic is handled manually?

Manually tracking certificate validity, key storage, and revocation status increases the risk of over-long-lived certificates going unnoticed, private keys shipped in plaintext without anyone catching it during review, and revocation gaps that leave compromised certificates trusted far longer than they should be.

Which teams should own this change?

PKI administrators own the day-to-day validity, key storage, and revocation configuration; security architects design the risk controls into the PKI up front; platform teams implement key storage and revocation checking in the product or device; compliance teams map these controls to the relevant framework; and CISOs own the residual risk decision.

How does this connect to certificate lifecycle management?

These three risk areas, validity, key protection, and revocation, are certificate lifecycle management questions: validity periods govern renewal cadence, key protection governs how securely each certificate’s private key survives issuance to expiration, and revocation governs how the lifecycle ends early when a certificate is compromised.

How should organizations measure success?

Success looks like every certificate’s validity period matching current algorithm guidance, zero private keys stored without hardware or encrypted protection, a revocation test that passes end to end, and a documented Certificate Policy that’s reviewed at least annually.

What should be audited or monitored regularly?

Organizations should audit certificate validity periods and algorithm currency quarterly, test revocation checking end to end on a recurring schedule, monitor CRL/OCSP endpoint uptime continuously, and review the Certificate Policy/CPS at least annually.

How does this topic affect cloud, hybrid, or multi-CA PKI?

Cloud and hybrid PKI deployments add third-party key management and revocation infrastructure that need the same risk review as an on-premises CA, and multi-CA environments require every issuing CA’s validity, key protection, and revocation posture to be assessed individually, since one weak CA in the hierarchy can undermine trust in the rest.

What common mistakes should teams avoid?

Common mistakes include picking the longest available certificate validity period without a renewal plan, storing private keys in plaintext on a device because it’s simpler to implement, assuming revocation isn’t needed because devices are offline most of the time, and never documenting the resulting Certificate Policy so the decisions get lost when the team changes.

What should be refreshed quarterly?

The certificate and algorithm inventory, the revocation endpoint monitoring configuration, and the risk matrix itself should be refreshed quarterly, since certificate validity periods, deprecated-algorithm timelines, and CA/Browser Forum requirements all change on a similar cadence.