Third-party certificate risk sits in an uncomfortable gap. It is your problem when something breaks, but it is not your certificate — you have no control over it, no direct ability to renew it, and typically no visibility into when it expires until your integration stops working.
Most certificate management processes focus entirely on certificates the organisation controls. This is rational — those are the ones you can actually renew. But it leaves a significant blind spot: the operational dependencies on supplier certificates that you cannot control but absolutely need to function. See how organisations approach supplier certificate compliance systematically.
How supplier certificate failures cause your incidents
The failure path is straightforward. Your application makes API calls to a supplier endpoint. The supplier's TLS certificate expires. Your HTTP client receives a certificate error. Depending on how your application handles TLS errors:
- If TLS errors are treated as hard failures (correct behaviour), your integration stops working immediately. Requests fail, errors propagate, and your service degrades or stops functioning depending on how critical the supplier is.
- If TLS errors are suppressed or ignored (incorrect but not uncommon), your application may continue operating but with unencrypted or unvalidated connections — a security failure that may not be immediately visible.
The incident is yours to deal with. Your users see errors. Your operations team investigates. They eventually identify that the root cause is a third-party certificate expiry. And then they contact the supplier, who may or may not respond quickly.
Resolution depends entirely on how fast the supplier renews their certificate. You cannot renew it for them. All you can do is wait — and manage the service degradation in the meantime.
Categories of supplier certificate exposure
Supplier certificate risk varies significantly by the nature of the dependency:
Critical path dependencies. Payment gateways, identity providers, core APIs that your primary functionality relies on. An expired certificate here is a P1 incident immediately. The blast radius matches your most critical user-facing functionality.
Non-critical but customer-visible dependencies. Third-party analytics, embedded content providers, optional feature APIs. An expired certificate causes degraded functionality or missing features — noticeable but not a complete outage.
Background processing dependencies. Data feeds, notification services, sync APIs. An expired certificate may cause silent failures — data stops syncing, notifications stop sending — that are not immediately visible but accumulate over time.
Internal supplier dependencies. Services provided by other teams within the same organisation — internal APIs, shared services, microservices operated by partner teams. These often have the same characteristics as external supplier dependencies but with more ability to escalate internally.
Why this is getting worse
Supplier certificate risk is increasing for several reasons:
Integration density is growing. Modern applications integrate with more third-party services than ever. Each integration is a potential certificate dependency. The more integrations, the more exposure.
47-day certificate lifetimes increase renewal frequency. As certificate lifetimes shorten, the renewal cadence for all certificates — including your suppliers' — accelerates. More renewals means more opportunities for renewal failures. A supplier that successfully managed annual renewals manually may struggle with renewing eight times per year.
Supplier certificate management maturity varies enormously. Large, mature technology companies typically have automated certificate management and rarely experience expiry issues. Smaller suppliers, niche vendors, and companies that do not primarily operate in the software industry may have poor certificate management practices — and the failure mode is the same regardless.
What you can do about it
You cannot renew a supplier's certificate for them. But there is more you can do than nothing:
Monitor supplier certificates and alert in advance. The same TLS certificate monitoring that covers your own estate can watch any endpoint you connect to, whether you own it or not. If your payment gateway's certificate expires in 14 days and your supplier has not renewed it, you will know in advance — giving you time to contact them before the failure, not after. See the guide on tracking supplier certificates automatically for a practical setup approach.
Include certificate monitoring in supplier assessment. When evaluating new suppliers or renewing contracts, ask about their certificate management practices. Do they have automated renewal? What is their process? This is a reasonable technical due diligence question, particularly for critical dependencies.
Include certificate requirements in SLAs. For critical supplier dependencies, consider including certificate management requirements in the service level agreement — valid certificates, minimum lead time for renewal, notification requirements. This gives you a contractual basis for expecting advance warning of certificate issues.
Build graceful degradation for critical integrations. For integrations where certificate failure would cause a P1 incident, design the integration to degrade gracefully — queuing transactions rather than failing, providing a manual fallback path, or caching the last known good state. This does not solve the certificate problem but limits the blast radius while you wait for the supplier to fix it.
Have a supplier escalation contact ready. When a supplier certificate expires, the clock is running. Having a direct technical escalation contact — not just a support ticket queue — can compress the response time significantly. For critical dependencies, this contact should be established before an incident occurs.
How CertControl monitors supplier certificates
CertControl can monitor any publicly reachable endpoint, regardless of whether you own the certificate. Adding a supplier API endpoint to the monitored certificate list gives you the same expiry tracking and alerting for that endpoint that you have for your own certificates.
This means you can know that a critical supplier's certificate expires in 30 days — in time to contact them, open a support case, or escalate to your account manager — rather than finding out when your integration breaks at 02:00 on a Sunday.
For supplier relationships covered by NIS2 supply chain requirements or ISO 27001 supplier security controls, the monitoring data provides audit evidence that supplier certificate health is actively tracked as part of your third-party risk management programme.
Frequently asked questions
Why is a supplier's expired certificate my problem?
Because your application depends on the supplier endpoint. When their TLS certificate expires your HTTP client rejects the connection, your integration breaks, and your users see errors — even though you cannot renew the certificate yourself.
What kinds of supplier dependencies carry certificate risk?
Critical-path dependencies like payment gateways and identity providers cause immediate P1 incidents. Customer-visible and background dependencies cause degraded features or silent failures. Internal supplier services behave similarly but are easier to escalate.
Why is supplier certificate risk getting worse?
Integration density keeps growing, 47-day lifetimes increase renewal frequency for every supplier, and supplier certificate management maturity varies enormously — smaller or non-software vendors are more likely to miss a renewal.
What can I do if I cannot renew a supplier certificate?
Monitor supplier endpoints and alert in advance, include certificate practices in supplier assessments and SLAs, build graceful degradation for critical integrations, and keep a direct technical escalation contact ready before an incident.
Does monitoring supplier certificates help with NIS2 and ISO 27001?
Yes. NIS2 supply chain requirements and ISO 27001 supplier security controls expect evidence that third-party risk is actively tracked. Continuous monitoring of supplier certificate health provides exactly that audit trail.