Third-Party Certificates: The Supply Chain Risk Hiding Inside Your Perimeter

Third-party certificate risk is the security exposure that remains when digital certificates issued to a vendor stay valid and trusted after the vendor relationship ends. Certificates are rarely governed through vendor offboarding the way user accounts, VPN access, and API keys are, making this one of the most overlooked supply chain risks in enterprise environments.

When a vendor is offboarded, procurement closes the contract, user accounts are deprovisioned, and VPN access is revoked. The mutual TLS certificate issued for their API integration is never registered in the systems offboarding touches, so it is never revoked. It continues to authenticate successfully long after the contract has ended.

This is the default behavior in most enterprise environments because certificate lifecycle management(CLM) and vendor risk management operate as completely separate functions. Certificates issued for third-party integrations, including client certificate access and credentials built on PKI, exist in a governance gap that neither team owns.

The Verizon 2025 DBIR found that third-party involvement in breaches doubled in one year, rising from 15% to 30% of all confirmed incidents. In most cases, the access vector was a credential that should have been revoked but was not. This blog examines how organizations can close that gap before a former vendor’s certificate becomes a breach vector.

How Certificates Grant Third-Party Access and Why That Access Is Different

To understand why third-party certificates represent a distinct and underappreciated risk, it helps to be specific about how they are used and what they actually grant.

Mutual TLS (mTLS) Authentication

Mutual TLS is a certificate-based authentication mechanism in which both the client and the server present digital certificates to verify each other’s identity before a connection is established. Unlike standard TLS, where only the server’s identity is verified, mTLS requires the connecting party to prove its own identity cryptographically.

This makes it the authentication mechanism of choice for API integrations between enterprises, service-to-service communication in zero-trust architectures, and any integration where the connecting party needs to be verified at the transport layer rather than through application-layer credentials.

For third-party integrations, mTLS is commonly implemented by issuing a certificate to the vendor or partner organization that their systems present when connecting to your APIs. That certificate is the credential that grants access. It is valid for its full validity period, which might be one year or longer, and it grants access every time it is presented to every system configured to trust it, regardless of any change in the business relationship after it was issued.

Client Authentication Certificates

Client authentication certificates, X.509 certificates with the Client Authentication extended key usage (EKU), are used to verify the identity of a client connecting to a server or service. They are functionally similar to mTLS but can be applied outside of full mutual TLS handshakes, for example, in VPN authentication, web application access control, or service mesh policies. For vendor integrations, client authentication certificates are often issued alongside or instead of username and password credentials as a more secure access mechanism.

The security advantage of certificate-based access over password-based access is real: certificates are stronger credentials that are resistant to phishing and credential-stuffing attacks, though private key theft or compromise at the endpoint remains a distinct risk category. The governance disadvantage is equally real: passwords expire or can be rotated on a schedule that aligns with vendor lifecycle events, while certificates often have no connection to vendor lifecycle management at all.

Code-Signing and Integration Pipeline Certificates

Some third-party integrations involve vendors who sign software artifacts, configuration packages, or data payloads that your systems process. The certificate used for signing is trusted by your infrastructure to validate those artifacts. If the vendor’s signing certificate is not revoked when the relationship ends, your infrastructure will continue to trust and process artifacts bearing that certificate’s signature, including, potentially, artifacts issued by whoever now controls the vendor’s systems or private key.

The Governance Gap: What Vendor Offboarding Misses

What makes all three certificate types particularly difficult to govern is not the technology, but the organisational distance between the teams that issue them and the teams that manage vendor relationships. Modern vendor offboarding processes have improved significantly in the past decade. Most organizations now maintain structured processes for deprovisioning vendor user accounts, revoking VPN and remote access, disabling API keys in secret management systems, and reviewing data access permissions. These steps are embedded in HR workflows, IAM systems, and vendor risk management platforms. They happen, imperfectly, but systematically.

Certificates fall through every one of those processes. Here is why, mapped across credential type:

Credential Type	Tracked for Vendor Offboarding?	Revocation on Contract End
User accounts	Yes, IAM system deactivates on offboarding	Usually automated
VPN access	Yes, VPN policy removes access on contract end	Usually automated
API keys	Partial, tracked in secret vaults if governed	Often manual, varies widely
mTLS certificates	Rarely, not tracked in most CLM systems	Almost always manual or missed
Integration certs	Rarely, issued and forgotten	Almost always missed entirely
Client auth certs (PKI)	Almost never, zero lifecycle governance	Not revoked in most orgs

The pattern is consistent: the more a credential looks like a user account (with a human owner, tracked in an identity system, subject to IAM governance), the more likely it is to be included in offboarding. The more a credential looks like infrastructure (a certificate embedded in a system configuration, tracked in no central system, issued by a PKI process that has no integration with vendor management), the less likely it is to be touched when the vendor relationship ends.

This is compounded by the fact that mTLS and client authentication certificates are often not managed by the same team that manages the vendor relationship. Procurement and vendor risk management manage the business relationship. The two functions rarely communicate specifically about certificate lifecycle events tied to vendor lifecycle events. A recent shift in public CA policy has added a new technical layer to this standing governance gap.

The 2026 mTLS Shift: A New Urgency for Third-Party Certificate Governance

A significant policy change that unfolded across the public CA ecosystem in 2025 and 2026 has added a new dimension of urgency to third-party certificate governance and created a concrete migration requirement for any organisation that was using public CA certificates for mTLS.

For years, organizations used publicly trusted TLS certificates, the same certificates that secure HTTPS connections, for mTLS and client authentication in vendor integrations. This was operationally convenient: public CAs would issue certificates that included both the Server Authentication and Client Authentication extended key usages, allowing a single certificate to serve both purposes.

That model has now ended for public certificates. The Chrome Root Program requires that public TLS certificates be scoped exclusively to server authentication. Major public certificate authorities began removing the Client Authentication EKU by default from newly issued TLS certificates starting in September 2025, with most completing their full removal by May 2026. Chrome began rejecting newly issued public TLS certificates that include the client authentication EKU as of June 15, 2026. DigiCert’s final cutoff for all issuances, including renewals and reissues, is March 1, 2027, and Chrome’s mandate for all public leaf certificates extends to March 15, 2027. As this transition takes full effect, organisations that built vendor mTLS integrations on public CA certificates will find those certificates becoming functionally broken for client authentication , often silently, during an automated renewal cycle, with no application-level warning until the connection fails.

The correct long-term answer, as the CA ecosystem has made clear, is to use private PKI for client authentication. Client certificates for vendor integrations should be issued from your own internal CA, under your own policy governance, with lifecycle management that you control. This is both technically correct and operationally necessary: a certificate issued from your private CA can be revoked immediately when a vendor contract ends, without depending on a public CA’s revocation infrastructure.

But private-CA-issued client certificates are exactly the certificates that most organizations have no visibility into, no lifecycle management for, and no connection to vendor offboarding processes. The transition that the CA ecosystem is forcing is, at the same time, a forcing function for the governance improvements that third-party certificate management has always needed. When those improvements are absent, the pattern of risk plays out in ways the industry has already documented.

Real-World Consequences: When Vendor Access Outlives the Contract

When the governance improvements that the CA ecosystem is now forcing are absent, the consequences follow a well-documented pattern. The risk of unrevoked vendor certificates is not hypothetical. The broader pattern, where third-party access credentials outlive the business relationship that justified them, is a recurring factor in real security incidents, and industry data shows how often credential-based access is the way attackers get in.

Verizon’s 2025 Data Breach Investigations Report identified stolen or misused credentials as the leading initial access vector, present in 22% of all breaches. The IBM X-Force Threat Intelligence Index 2025 found that valid account credential abuse ranked among the top two initial access vectors in incident response engagements, tied with exploitation of public-facing applications, with adversaries increasingly relying on legitimate credentials rather than novel malware.

A vendor certificate that was never revoked is exactly that: a valid credential, in an attacker’s possession or simply in an unmonitored state, granting access that should no longer exist.

Closing the Gap: A 5-Step Approach to Third-Party Certificate Governance

Closing the third-party certificate governance gap requires connecting two functions that have historically operated independently: certificate lifecycle management and vendor risk management. The following five-step approach reflects how organizations with mature programs have built that connection.

1. Discover All Third-Party Certificates in Your Environment
   Run automated certificate discovery across all environments: Windows stores, IIS, Linux servers, load balancers, API gateways, and containers. Filter results to identify certificates issued to external organizations by examining Subject CN, SANs, and issuing CA. This is the baseline inventory you have probably never had.

2. Map Each Certificate to a Vendor Relationship
   For each third-party certificate found, establish the business relationship it corresponds to: which vendor or contractor was it issued for, who owns the relationship, when does the contract expire or renew, and what systems does the certificate grant access to.

   Code-signing certificates held by vendors require explicit attention at this stage: unlike TLS certificates, which break cleanly when revoked, a vendor’s signing certificate continues to validate previously signed artifacts even after the vendor relationship ends, unless those artifacts are removed or the certificate is distrusted. Certificates with no identifiable business relationship should be treated as high-risk orphans and investigated immediately.

3. Integrate Certificate Lifecycle into Vendor Onboarding and Offboarding
   Create a formal checkpoint in your vendor onboarding process where any certificates issued to the vendor are registered in a certificate lifecycle management (CLM) platform with the contract end date, owning team, and access scope.

   If your organisation does not yet operate a CLM platform, Step 3 is the point where that investment pays off most clearly: the automated inventory built in Step 1 is only actionable at scale if it is stored in a system that can trigger alerts and workflow automations when contract dates or certificate attributes change.

   Create a corresponding offboarding checkpoint that triggers certificate revocation as part of the vendor exit process, alongside the user account and VPN removal steps that already exist.

4. Enforce Short Validity Periods for All Vendor Certificates
   Avoid issuing long-lived certificates for vendor integrations on the basis of operational convenience. Short validity periods , 90 days or less , create a natural revalidation cadence that confirms the vendor relationship remains active and the certificate is still required. When a certificate expires without renewal, access terminates automatically rather than persisting indefinitely.

5. Audit Periodically for Certificates That Outlived Their Contract
   Even with improved governance going forward, existing environments will carry legacy certificates from past vendor relationships. Schedule quarterly discovery runs specifically targeted at identifying certificates whose associated contract has expired. These are the standing backdoors that were created before governance was in place.

Security Considerations

Improving third-party certificate governance reduces a real and underappreciated attack surface. The transition also involves security decisions that deserve careful attention.

When migrating vendor integrations from public-CA client authentication certificates to private-CA-issued certificates, coordinate the transition carefully with each vendor. A certificate that stops working unexpectedly because of a CA policy change, rather than a planned cutover, creates both an operational disruption and a security response burden.

Short validity periods for vendor certificates are a security control, not an administrative inconvenience. Decline requests from vendors to extend certificate lifetimes on grounds of operational convenience. The renewal overhead is preferable to the alternative: a certificate that remains valid for two years without any review.

Establish a formal process for emergency revocation of vendor certificates, one that can be executed in hours, not days. If a vendor relationship ends under adversarial circumstances, or if a vendor notifies you of a security incident, the ability to revoke all certificates associated with that vendor immediately is a critical incident response capability.

Monitor for usage of vendor certificates after business hours or from unexpected source addresses. A valid certificate connecting from an IP address that does not belong to the vendor is not necessarily a vendor action; it may indicate that the certificate has been stolen or the vendor’s systems have been compromised.

For vendor integrations involving access to sensitive systems or regulated data, build annual certificate reviews into vendor contract renewal processes. Treat certificate continuation as a conscious decision rather than a passive default.

How Encryption Consulting Helps

Encryption Consulting works with enterprises to close the governance gap between certificate lifecycle management and vendor risk management, building programs that ensure third-party certificates are discovered, governed, and revoked as part of the standard vendor lifecycle rather than as an afterthought.

Our advisory engagements begin with a third-party certificate discovery assessment: identifying all certificates currently in your environment that were issued to or for external parties, mapping them to active and expired vendor relationships, and producing a prioritized risk inventory of certificates that should be reviewed, renewed, or revoked.

For organizations ready to deploy CertSecure Manager, our implementation team integrates certificate lifecycle into your existing vendor offboarding workflows, builds the private CA infrastructure needed for client authentication, and establishes the monitoring and alerting that makes ongoing governance sustainable.

CertSecure Manager

CertSecure Manager is Encryption Consulting’s enterprise certificate lifecycle management platform, built to give security and operations teams centralized visibility and control over their full certificate inventory, including the third-party and integration certificates that external tools cannot reach.

For third-party certificate governance specifically, CertSecure Manager provides the discovery and policy enforcement capabilities that connect CLM to vendor lifecycle management. Discovery identifies all certificates currently in the environment, including those issued to external organizations, and normalizes them into a unified inventory with ownership assignment and expiry tracking.

Policy enforcement can be configured to flag certificates tied to expired vendor contracts, trigger revocation workflows when vendor offboarding events occur, and alert when any certificate approaches expiry without a renewal or revocation decision in progress.

• Automated Discovery: Discovery of third-party certificates across all environments, with subject and issuing CA analysis to identify certificates issued to external entities.
• Vendor Ownership Mapping: Ownership assignment linking each discovered certificate to a vendor relationship, contract owner, and expiry date, connecting CLM data to vendor management context.
• Offboarding Integration: Revocation workflow integration that can be triggered by vendor offboarding events, ensuring certificate revocation happens as part of the standard contract exit process rather than as a separate, forgettable step.
• Validity Enforcement: Short-validity-period enforcement for all vendor-facing certificates, with automated renewal requests and alerts when certificates approach expiry without a clear renewal or revocation decision.
• Private CA Integration for Client Auth: Support for deploying or integrating with private CA infrastructure to issue client authentication certificates for vendor integrations, ensuring vendor mTLS credentials are governed under your organisation’s own policy framework rather than depending on public CA policies that continue to evolve.

The supply chain risk inside your perimeter is not a new category of threat. It is a governance gap in a credential type that most organizations have never systematically managed. The organizations that close that gap now are the ones that will not find themselves explaining, after the fact, why a vendor whose contract ended a year ago still had working access to a production system.

Conclusion

When a vendor relationship ends, the offboarding checklist runs: user accounts are deprovisioned, VPN access is revoked, and API keys are disabled. And the certificate (the mutual TLS credential that the vendor’s systems use to authenticate to your API gateway, your internal services, your integration endpoints) remains valid and active, connected to no offboarding process, tracked in no system that security or vendor risk management controls.

This is not a rare configuration. It is the norm in enterprise environments where certificate lifecycle management and vendor risk management have never been connected. The 85% of CISOs who cannot see third-party threats beyond their direct suppliers, the 70% who experienced a material third-party incident last year, the 61% who had a breach caused by a third party: the credential gap inside the perimeter is a significant and underestimated contributor to all of those numbers.

The 2025–2026 shift in public CA policies for client authentication, which removed the Client Authentication EKU from publicly trusted TLS certificates, has served as a forcing function. Organizations that have relied on public CA certificates for vendor mTLS need to migrate to private PKI. And private PKI certificates are exactly the kind of credential that requires the lifecycle governance that most organizations have not yet built.

To learn more about how CertSecure Manager helps enterprises discover and govern third-party certificates, or to discuss a third-party certificate assessment with our team, contact Encryption Consulting.