Tredjepartscertifikat: Risken med leveranskedjan som gömmer sig innanför din perimeter

Risk med tredjepartscertifikat är den säkerhetsexponering som kvarstår när digitala certifikat som utfärdats till en leverantör förblir giltiga och betrodda efter att leverantörsrelationen upphör. Certifikat styrs sällan genom leverantörsoffboarding på samma sätt som användarkonton, VPN-åtkomst och API-nycklar, vilket gör detta till en av de mest förbisedda riskerna i leveranskedjan i företagsmiljöer.

När en leverantör offboardas stängs kontraktet av upphandlingsavdelningen, användarkonton avprovisioneras och VPN-åtkomst återkallas. Det ömsesidiga TLS- certifikatet som utfärdats för deras API-integration registreras aldrig i systemets offboarding-kontakter, så det återkallas aldrig. Det fortsätter att autentiseras framgångsrikt långt efter att kontraktet har löpt ut.

Detta är standardbeteendet i de flesta företagsmiljöer eftersom certifikatlivscykelhantering (CLM) och leverantörsriskhantering fungerar som helt separata funktioner. Certifikat som utfärdats för tredjepartsintegrationer, inklusive klientcertifikatåtkomst och autentiseringsuppgifter byggda på PKI , finns i en styrningslucka som inget av teamen äger.

Verizons 2025 DBIR fann att tredjepartsinblandning i dataintrång fördubblades på ett år, från 15 % till 30 % av alla bekräftade incidenter. I de flesta fall var åtkomstvektorn en autentiseringsuppgifter som borde ha återkallats men inte blev det. Den här bloggen undersöker hur organisationer kan täppa till den luckan innan en tidigare leverantörs certifikat blir en intrångsvektor.

Hur certifikat ger åtkomst till tredje part och varför den åtkomsten är annorlunda

För att förstå varför tredjepartscertifikat utgör en tydlig och underskattad risk är det bra att vara specifik om hur de används och vad de faktiskt beviljar.

Ömsesidig TLS (mTLS) autentisering

Mutual TLS är en certifikatbaserad autentiseringsmekanism där både klienten och servern presenterar digitala certifikat för att verifiera varandras identitet innan en anslutning upprättas. Till skillnad från standard TLS, där endast serverns identitet verifieras, kräver mTLS att den anslutande parten bevisar sin egen identitet kryptografiskt.

Detta gör den till den autentiseringsmekanismen man väljer för API-integrationer mellan företag, tjänst-till-tjänst-kommunikation i nolltrust-arkitekturer och alla integrationer där den anslutande parten behöver verifieras på transportlagret snarare än genom autentiseringsuppgifter på applikationslagret.

För tredjepartsintegrationer implementeras mTLS vanligtvis genom att utfärda ett certifikat till leverantören eller partnerorganisationen som deras system presenterar vid anslutning till dina API:er. Det certifikatet är den autentiseringsuppgift som ger åtkomst. Det är giltigt under hela sin giltighetstid, vilket kan vara ett år eller längre, och det ger åtkomst varje gång det presenteras för alla system som är konfigurerade att lita på det, oavsett eventuella förändringar i affärsrelationen efter att det utfärdades.

Klientautentiseringscertifikat

Klientautentiseringscertifikat, X.509 -certifikat med Client Authentication Extended Key Usage (EKU), används för att verifiera identiteten på en klient som ansluter till en server eller tjänst. De är funktionellt lika mTLS men kan tillämpas utanför fullständiga ömsesidiga TLS-handskakningar, till exempel i VPN-autentisering, åtkomstkontroll för webbapplikationer eller policyer för tjänstnät. För leverantörsintegrationer utfärdas klientautentiseringscertifikat ofta tillsammans med eller istället för användarnamn och lösenord som en säkrare åtkomstmekanism.

Säkerhetsfördelen med certifikatbaserad åtkomst jämfört med lösenordsbaserad åtkomst är verklig: certifikat är starkare autentiseringsuppgifter som är motståndskraftiga mot nätfiske och attacker med stöld av autentiseringsuppgifter, även om stöld eller kompromettering av privata nycklar vid slutpunkten fortfarande är en tydlig riskkategori. Nackdelen med styrning är lika verklig: lösenord löper ut eller kan roteras enligt ett schema som överensstämmer med leverantörens livscykelhändelser, medan certifikat ofta inte har någon koppling till leverantörens livscykelhantering alls.

Kodsignering och integrationspipeline-certifikat

Vissa tredjepartsintegrationer involverar leverantörer som signerar programvaruartefakter, konfigurationspaket eller datanylaster som dina system bearbetar. Certifikatet som används för signering är betrott av din infrastruktur för att validera dessa artefakter. Om leverantörens signeringscertifikat inte återkallas när relationen upphör, kommer din infrastruktur att fortsätta att lita på och bearbeta artefakter som bär certifikatets signatur, inklusive potentiellt artefakter som utfärdats av den som nu kontrollerar leverantörens system eller privata nyckel.

Styrningsgapet: Vad leverantörsoffboarding missar

Det som gör alla tre certifikattyper särskilt svåra att styra är inte tekniken, utan det organisatoriska avståndet mellan de team som utfärdar dem och de team som hanterar leverantörsrelationer. Moderna processer för att ta bort leverantörer har förbättrats avsevärt under det senaste decenniet. De flesta organisationer har nu strukturerade processer för att avprovisionera leverantörsanvändarkonton, återkalla VPN- och fjärråtkomst, inaktivera API-nycklar i hemliga hanteringssystem och granska dataåtkomstbehörigheter. Dessa steg är inbäddade i HR-arbetsflöden, IAM-system och plattformar för riskhantering för leverantörer. De sker, ofullständigt, men systematiskt.

Certifikat går igenom alla dessa processer. Här är anledningen, mappade över olika autentiseringsuppgifter:

Typ av behörighet	Spåras för leverantörsoffboarding?	Återkallelse vid kontraktets slut
Användarkonton	Ja, IAM-systemet inaktiveras vid offboarding	Vanligtvis automatiserad
VPN-åtkomst	Ja, VPN-policyn tar bort åtkomst när kontraktet slutar	Vanligtvis automatiserad
API-nycklar	Delvis, spåras i hemliga valv om styrt	Ofta manuell, varierar kraftigt
mTLS-certifikat	Sällan, spåras inte i de flesta CLM-system	Nästan alltid manuellt eller missat
Integrationscertifikat	Sällan, utfärdad och bortglömd	Missade nästan alltid helt
Klientautentiseringscertifikat (PKI)	Nästan aldrig, noll livscykelstyrning	Inte återkallad i de flesta organisationer

Mönstret är konsekvent: ju mer en autentiseringsuppgifter ser ut som ett användarkonto (med en mänsklig ägare, spårad i ett identitetssystem, underlagt IAM-styrning), desto mer sannolikt är det att de inkluderas i offboarding. Ju mer en autentiseringsuppgifter ser ut som infrastruktur (ett certifikat inbäddat i en systemkonfiguration, spårat i inget centralt system, utfärdat av en PKI-process som inte har någon integration med leverantörshantering), desto mindre sannolikt är det att de berörs när leverantörsrelationen upphör.

Detta förvärras av det faktum att mTLS- och klientautentiseringscertifikat ofta inte hanteras av samma team som hanterar leverantörsrelationen. Upphandling och riskhantering för leverantörer hanterar affärsrelationen. De två funktionerna kommunicerar sällan specifikt om certifikatlivscykelhändelser kopplade till leverantörslivscykelhändelser. En nyligen genomförd förändring i offentlig CA-policy har lagt till ett nytt tekniskt lager till denna bestående styrningsgap.

mTLS-skiftet 2026: En ny brådska för styrning av tredjepartscertifikat

En betydande policyförändring som genomfördes inom det offentliga CA-ekosystemet under 2025 och 2026 har lagt till en ny dimension av brådska i styrningen av tredjepartscertifikat och skapat ett konkret migreringskrav för alla organisationer som använde offentliga CA-certifikat för mTLS.

I åratal använde organisationer offentligt betrodda TLS-certifikat, samma certifikat som säkrar HTTPS-anslutningar, för mTLS och klientautentisering i leverantörsintegrationer. Detta var operativt bekvämt: offentliga certifikatutfärdare utfärdade certifikat som inkluderade både serverautentisering och klientautentisering för utökade nyckelanvändningar, vilket gjorde att ett enda certifikat kunde tjäna båda syftena.

Den modellen har nu upphört för offentliga certifikat. Chromes rotprogram kräver att offentliga TLS-certifikat exklusivt ska omfatta serverautentisering. Stora offentliga certifikatutfärdare började ta bort klientautentiserings-EKU som standard från nyutfärdade TLS-certifikat från och med september 2025, och de flesta slutförde sin fullständiga borttagning senast i maj 2026. Chrome började avvisa nyutfärdade offentliga TLS-certifikat som inkluderar klientautentiserings-EKU från och med den 15 juni 2026. DigiCerts slutgiltiga tidsfrist för alla utfärdanden, inklusive förnyelser och återutgivningar, är den 1 mars 2027, och Chromes mandat för alla offentliga lövcertifikat sträcker sig till den 15 mars 2027. När denna övergång träder i kraft fullt ut kommer organisationer som byggt leverantörs-mTLS-integrationer på offentliga CA-certifikat att upptäcka att dessa certifikat inte fungerar korrekt för klientautentisering, ofta tyst, under en automatiserad förnyelsecykel, utan varning på applikationsnivå förrän anslutningen misslyckas.

Det korrekta långsiktiga svaret, som CA-ekosystemet har tydliggjort, är att använda privat PKI för klientautentisering. Klientcertifikat för leverantörsintegrationer bör utfärdas från din egen interna CA, under din egen policystyrning, med livscykelhantering som du kontrollerar. Detta är både tekniskt korrekt och operativt nödvändigt: ett certifikat som utfärdats från din privata CA kan återkallas omedelbart när ett leverantörskontrakt upphör, utan att vara beroende av en offentlig CA:s återkallningsinfrastruktur.

Men privata klientcertifikat utfärdade av certifikatutfärdare är just de certifikat som de flesta organisationer inte har någon insyn i, ingen livscykelhantering för och ingen koppling till leverantörers offboarding-processer. Den övergång som certifikatutfärdarens ekosystem tvingar fram är samtidigt en påtvingande funktion för de styrningsförbättringar som tredjepartscertifikathantering alltid har behövt. När dessa förbättringar saknas spelar riskmönstret ut på sätt som branschen redan har dokumenterat.

Konsekvenser i verkligheten: När leverantörsåtkomst överlever kontraktet

När de styrningsförbättringar som CA-ekosystemet nu tvingar fram uteblir följer konsekvenserna ett väl dokumenterat mönster. Risken för oåterkallade leverantörscertifikat är inte hypotetisk. Det bredare mönstret, där tredjepartsåtkomstuppgifter överlever den affärsrelation som motiverade dem, är en återkommande faktor i verkliga säkerhetsincidenter, och branschdata visar hur ofta autentiseringsbaserad åtkomst är det sätt angripare tar sig in.

Verizons rapport om dataintrångsutredningar från 2025 identifierade stulna eller missbrukade inloggningsuppgifter som den ledande initiala åtkomstvektorn, närvarande i 22 % av alla intrång. IBM X-Force Threat Intelligence Index 2025 fann att missbruk av giltiga kontouppgifter rankades bland de två främsta initiala åtkomstvektorerna i incidenthantering, kopplat till utnyttjande av offentligt riktade applikationer, där motståndare i allt högre grad förlitar sig på legitima inloggningsuppgifter snarare än ny skadlig kod.

Ett leverantörscertifikat som aldrig återkallades är just det: en giltig autentiseringsuppgift, i en angripares besittning eller helt enkelt i ett oövervakat tillstånd, som ger åtkomst som inte längre borde existera.

Att minska gapet: En 5-stegsstrategi för tredjepartscertifikatstyrning

Att överbrygga gapet i styrningen av tredjepartscertifikat kräver att två funktioner som historiskt sett har fungerat oberoende av varandra kopplas samman: hantering av certifikatlivscykeln och hantering av leverantörsrisker. Följande femstegsmetod återspeglar hur organisationer med mogna program har byggt den kopplingen.

1. Upptäck alla tredjepartscertifikat i din miljö
   Kör automatiserat certifikat Upptäckten i alla miljöer: Windows-butiker, IIS, Linux-servrar, lastbalanserare, API-gateways och behållareFiltrera resultat för att identifiera certifikat utfärdade till externa organisationer genom att undersöka ämnes-CN, SAN och utfärdande CA. Detta är den grundläggande inventering som du förmodligen aldrig har haft.

2. Mappa varje certifikat till en leverantörsrelation
   För varje tredjepartscertifikat som hittas, fastställ vilken affärsrelation det motsvarar: vilken leverantör eller entreprenör det utfärdades för, vem äger relationen, när kontraktet löper ut eller förnyas och vilka system certifikatet ger åtkomst till.

   Kodsigneringscertifikat som innehas av leverantörer kräver uttrycklig uppmärksamhet i detta skede: till skillnad från TLS-certifikat, som slutar fungera direkt när de återkallas, fortsätter ett leverantörs signeringscertifikat att validera tidigare signerade artefakter även efter att leverantörsrelationen upphör, såvida inte dessa artefakter tas bort eller certifikatet misstrotts. Certifikat utan identifierbar affärsrelation bör behandlas som högriskcertifikat och omedelbart undersökas.

3. Integrera certifikatlivscykeln i leverantörsonboarding och -offboarding
   Skapa en formell kontrollpunkt i din leverantörs onboardingprocess där alla certifikat som utfärdas till leverantören registreras i en plattform för certifikatlivscykelhantering (CLM) med kontraktets slutdatum, ägande team och åtkomstomfattning.

   Om er organisation ännu inte använder en CLM-plattform är steg 3 den punkt där investeringen lönar sig tydligast: den automatiserade inventeringen som byggdes i steg 1 är endast användbar i stor skala om den lagras i ett system som kan utlösa aviseringar och automatiseringar av arbetsflöden när kontraktsdatum eller certifikatattribut ändras.

   Skapa en motsvarande offboarding-kontrollpunkt som utlöser återkallelse av certifikat som en del av leverantörsutträdesprocessen, tillsammans med de steg för borttagning av användarkonto och VPN som redan finns.

4. Tillämpa korta giltighetsperioder för alla leverantörscertifikat
   Undvik att utfärda långlivade certifikat för leverantörsintegrationer baserat på driftsmässig bekvämlighet. Korta giltighetsperioder , 90 dagar eller mindre, skapa en naturlig omvalideringskadens som bekräftar att leverantörsrelationen förblir aktiv och att certifikatet fortfarande krävs. När ett certifikat löper ut utan förnyelse avslutas åtkomsten automatiskt istället för att bestå på obestämd tid.

5. Regelbunden granskning av certifikat som har överskridit sitt avtal
   Även med förbättrad styrning framöver kommer befintliga miljöer att bära äldre certifikat från tidigare leverantörsrelationer. Schemalägg kvartalsvisa identifieringskörningar specifikt inriktade på att identifiera certifikat vars tillhörande kontrakt har löpt ut. Dessa är de befintliga bakdörrarna som skapades innan styrning var på plats.

Säkerhetsöverväganden

Att förbättra styrningen av tredjepartscertifikat minskar en verklig och underskattad attackyta. Övergången innebär också säkerhetsbeslut som förtjänar noggrann uppmärksamhet.

När du migrerar leverantörsintegrationer från klientautentiseringscertifikat för offentliga CA-er till certifikat utfärdade av privata CA-er, koordinera övergången noggrant med varje leverantör. Ett certifikat som slutar fungera oväntat på grund av en CA-policyändring, snarare än en planerad övergång, skapar både driftstörningar och en säkerhetsmässig belastning.

Korta giltighetsperioder för leverantörscertifikat är en säkerhetskontroll, inte en administrativ olägenhet. Avvisa förfrågningar från leverantörer om att förlänga certifikatens livslängd av skäl som underlättar driften. Förnyelsekostnaden är att föredra framför alternativet: ett certifikat som förblir giltigt i två år utan någon granskning.

Upprätta en formell process för akut återkallelse av leverantörscertifikat, en process som kan verkställas på timmar, inte dagar. Om en leverantörsrelation upphör under kontradiktoriska omständigheter, eller om en leverantör meddelar dig om en säkerhetsincident, är möjligheten att omedelbart återkalla alla certifikat som är kopplade till den leverantören en kritisk incidenthanteringsfunktion.

Övervaka användningen av leverantörscertifikat efter kontorstid eller från oväntade källadresser. Ett giltigt certifikat som ansluter från en IP-adress som inte tillhör leverantören är inte nödvändigtvis en leverantörsåtgärd; det kan tyda på att certifikatet har blivit stulet eller att leverantörens system har komprometterats.

För leverantörsintegrationer som involverar åtkomst till känsliga system eller reglerad data, integrera årliga certifikatgranskningar i leverantörernas avtalförnyelseprocesser. Betrakta certifikatfortsättning som ett medvetet beslut snarare än ett passivt försummelsebeslut.

Hur krypteringskonsulting hjälper

Encryption Consulting arbetar med företag för att minska gapet mellan hantering av certifikatlivscykeln och riskhantering för leverantörer. Vi bygger program som säkerställer att tredjepartscertifikat upptäcks, styrs och återkallas som en del av leverantörens standardlivscykel snarare än som en eftertanke.

Våra rådgivningsuppdrag börjar med en tredjepartsbedömning av certifikatidentifiering: vi identifierar alla certifikat som för närvarande finns i din miljö och som utfärdats till eller för externa parter, mappar dem till aktiva och utgångna leverantörsrelationer och skapar en prioriterad riskinventering av certifikat som bör granskas, förnyas eller återkallas.

För organisationer som är redo att driftsätta CertSecure Manager integrerar vårt implementeringsteam certifikatlivscykeln i era befintliga arbetsflöden för leverantörsoffboarding, bygger den privata CA-infrastruktur som behövs för klientautentisering och etablerar övervakning och aviseringar som gör den kontinuerliga styrningen hållbar.

CertSecure-hanterare

CertSecure Manager är Encryption Consultings plattform för hantering av företagscertifikats livscykel, byggd för att ge säkerhets- och driftsteam centraliserad insyn och kontroll över hela deras certifikatinventering, inklusive tredjeparts- och integrationscertifikat som externa verktyg inte kan nå.

Specifikt för tredjepartscertifikatstyrning tillhandahåller CertSecure Manager funktioner för identifiering och policytillämpning som kopplar CLM till leverantörslivscykelhantering. Identifieringen identifierar alla certifikat som för närvarande finns i miljön, inklusive de som utfärdats till externa organisationer, och normaliserar dem till en enhetlig inventering med ägartilldelning och spårning av utgångsdatum.

Policytillämpning kan konfigureras för att flagga certifikat kopplade till utgångna leverantörskontrakt, utlösa återkallningsarbetsflöden när leverantörsavregistreringar inträffar och avisera när ett certifikat närmar sig utgångsdatum utan att ett beslut om förnyelse eller återkallelse pågår.

• Automatiserad upptäckt: Identifiering av tredjepartscertifikat i alla miljöer, med analys av ämnes- och utfärdande certifikatutfärdare för att identifiera certifikat som utfärdats till externa enheter.
• Kartläggning av leverantörsägarskap: Ägarskapstilldelning som länkar varje upptäckt certifikat till en leverantörsrelation, kontraktsägare och utgångsdatum, och kopplar CLM-data till leverantörshanteringskontexten.
• Offboarding-integration: Integrering av arbetsflöden för återkallelse som kan utlösas av leverantörsoffboarding-händelser, vilket säkerställer att certifikatåterkallelse sker som en del av standardprocessen för kontraktsavslut snarare än som ett separat, glömbart steg.
• Giltighetskontroll: Kort giltighetstid för alla leverantörsrelaterade certifikat, med automatiserade förnyelseförfrågningar och aviseringar när certifikat närmar sig utgångsdatum utan ett tydligt beslut om förnyelse eller återkallelse.
• Privat CA-integration för klientautentisering: Stöd för att distribuera eller integrera med privat CA-infrastruktur för att utfärda klientautentiseringscertifikat för leverantörsintegrationer, vilket säkerställer att leverantörers mTLS-autentiseringsuppgifter styrs av din organisations eget policyramverk snarare än att vara beroende av offentliga CA-policyer som ständigt utvecklas.

Risken i leveranskedjan inom er perimeter är inte en ny hotkategori. Det är ett styrningsgap av en typ av behörighet som de flesta organisationer aldrig systematiskt har hanterat. De organisationer som täcker det gapet nu är de som inte kommer att behöva förklara i efterhand varför en leverantör vars kontrakt löpte ut för ett år sedan fortfarande hade fungerande tillgång till ett produktionssystem.

Slutsats

När en leverantörsrelation avslutas körs checklistan för offboarding: användarkonton avprovisioneras, VPN-åtkomst återkallas och API-nycklar inaktiveras. Och certifikatet (den ömsesidiga TLS-autentiseringsuppgifter som leverantörens system använder för att autentisera mot din API-gateway, dina interna tjänster, dina integrationsslutpunkter) förblir giltigt och aktivt, anslutet till ingen offboardingprocess, spåras inte i något system som säkerhets- eller leverantörsriskhantering kontrollerar.

Detta är inte en ovanlig konfiguration. Det är normen i företagsmiljöer där certifikatlivscykelhantering och leverantörsriskhantering aldrig har kopplats samman. De 85 % av CISO:erna som inte kan se hot från tredje part utöver sina direkta leverantörer, de 70 % som upplevde en väsentlig tredjepartsincident förra året, de 61 % som hade ett dataintrång orsakat av en tredje part: autentiseringsgapet inom perimetern är en betydande och underskattad bidragande faktor till alla dessa siffror.

Förändringen 2025–2026 i offentliga CA-policyer för klientautentisering, som tog bort klientautentiserings-EKU från offentligt betrodda TLS-certifikat, har fungerat som en tvingande funktion. Organisationer som har förlitat sig på offentliga CA-certifikat för leverantörs-mTLS behöver migrera till privata PKI. Och privata PKI-certifikat är precis den typ av autentiseringsuppgifter som kräver den livscykelstyrning som de flesta organisationer ännu inte har byggt.

För att lära dig mer om hur CertSecure Manager hjälper företag att upptäcka och hantera tredjepartscertifikat, eller för att diskutera en bedömning av tredjepartscertifikat med vårt team, kontakta Encryption Consulting.