Explosionen av icke-mänsklig identitet

Icke-mänskliga identiteter (NHI), inklusive API-nycklar, tjänstkonton, tokens, certifikat och AI-agenter, överträffar nu mänskliga identiteter i företagsmiljöer med ungefär 82 mot 1, men de flesta säkerhetsverktyg, processer och styrningsramverk byggdes för människor. Maskiner autentiserar med hemligheter, inte lösenord och MFA-prompter, och de sprids i programvaruhastighet medan organisationer fortfarande hanterar dem i mänsklig hastighet. Den rekommenderade åtgärden: inventera varje NHI i din miljö, tilldela varje en namngiven ägare, tillämpa lägsta behörighet, ersätt långlivade statiska hemligheter med kortlivade automatiskt roterande autentiseringsuppgifter och automatisera avveckling så att pensionering av en tjänst också pensionerar dess autentiseringsuppgifter.

Snabbt svar: Vad är den icke-mänskliga identitetsexplosionen och varför spelar den roll?

NHI-explosionen hänvisar till den snabba ackumuleringen av maskinuppgifter i företagsmiljöer, inklusive API-nycklar, servicekonton, OAuth-tokens, TLS-certifikat, SSH-nycklar, moln-IAM-roller och AI-agentidentiteter, som nu vida överstiger antalet mänskliga konton. I de flesta organisationer är antalet maskiner 82 gånger större än antalet människor. Det är viktigt eftersom dessa uppgifter är den attackyta som angripare nu föredrar: de har ingen MFA-prompt, ingen HR-offboardingprocess, ingen utgångsmekanism och de får rutinmässigt överbehörigheter. När en maskinuppgifter komprometteras ärver angriparen all dess åtkomst, ofta administrativ åtkomst till produktionssystem, utan något mänskligt beteendemönster som utlöser upptäckt. Efterlevnadsmiljön 2026 har skärpt denna brådska: PCI DSS 4.0 (krav 8.6.1-8.6.3, fullt verkställbara sedan mars 2025) kräver uttryckligen noggrann hantering av applikations- och systemkonton, och att förkorta TLS-certifikatens livslängd (200 dagar nu, 47 dagar år 2029) innebär att certifikatautomation inte längre är valfritt.

Vad är en icke-mänsklig identitet?

En icke-mänsklig identitet är en digital autentiseringsuppgift som används av programvara snarare än en person. En människa bevisar identitet med ett lösenord och kanske ett fingeravtryck. Programvara kan inte göra det, så den använder istället en hemlighet: en token, en API-nyckel, ett certifikat eller en nyckel. Det mottagande systemet kontrollerar hemligheten och beviljar åtkomst. Vanliga NHI-typer inkluderar:

• Servicekonton: autentiseringsuppgifter som tillåter ett program att ansluta till en databas, meddelandekö eller annan tjänst utan mänsklig inloggning.
• API-nycklar och OAuth-tokens: hemligheter som ger en applikation åtkomst till en annans data eller funktioner. Till exempel ett SaaS-verktyg som läser poster från ditt CRM.
• Cloud IAM-roller: identitetskonstruktioner i AWS, Azure eller Google Cloud som tillåter en arbetsbelastning (en Lambda-funktion, en virtuell maskin, en container) att komma åt andra molnresurser utan statiska autentiseringsuppgifter.
• CI/CD-pipeline-inloggningsuppgifter, SSH-nycklaroch TLS-certifikat: hemligheter som säkrar maskin-till-maskin-anslutningar i bygg- och distributionspipelines.
• AI-agenter: autonoma programvarusystem som anropar API:er och vidtar åtgärder på egen hand. Detta är den nyaste och snabbast växande NHI-kategorin, där varje agent kräver sin egen behörighet.

Termen maskinidentitet är nära besläktad. Maskinidentitet syftar vanligtvis på autentiseringsuppgifter för enheter och arbetsbelastningar; NHI är den bredare termen som även omfattar programvaru-till-programvaru-anslutningar och autentiseringsuppgifter för AI-agenter. För styrningsändamål, behandla dem som ett problemområde.

Varför växer icke-mänskliga identiteter så snabbt?

NHI:er är inte nya. Det som förändrats är den takt med vilken de förökar sig. Tre krafter orsakade det.

1. Molnbaserad arkitektur delade upp applikationer: Moderna applikationer kör lika många små tjänster som en enda monolitisk kodbas. Varje mikrotjänst behöver sin egen identitet för att autentisera sig mot de andra. Med containrar och Kubernetes, tjänster startar och stoppar kontinuerligt, vilket skapar och tar bort hundratals identiteter per dag för en enda applikation.
2. Automatisering skapar inloggningsuppgifter programmatiskt: Varje pipeline, integration och infrastruktur-som-kod-skript kan tillhandahålla nya inloggningsuppgifter automatiskt. Vissa NHI:er skapar till och med andra NHI:er, vilket förvärrar ackumuleringsproblemet.
3. AI-agenter tillförde exponentiellt bränsle: moderna AI-medel svarar inte bara på frågor. De vidtar åtgärder, anropar API:er och får åtkomst till känsliga system. Varje agent är en ny identitet som kräver inloggningsuppgifter. Microsoft rapporterade kunder skapade över en miljon anpassade AI-agenter i SharePoint och Copilot Studio under ett enda kvartal. Många agenter har delegerade mänskliga inloggningsuppgifter, vilket gör det svårt att tillskriva åtgärder till en specifik person.

Resultatet: maskiner skapar identiteter i mjukvaruhastighet medan organisationer hanterar dem i mänsklig hastighet. Gartner förväntar sig att gapet mellan maskin- och mänskliga identiteter kommer att fortsätta att öka i takt med att molnanvändning och implementering av AI-agenter accelererar.

Styrningsgapet: Varför mänskliga kontroller misslyckas på maskiner

Kärnproblemet är att identitetsverktyg byggdes för människor. NHI:er beter sig inte som människor. Den obalansen skapar tre sammansatta problem.

1. Mänskliga kontroller gäller inte: UD kräver en telefon eller ett fingeravtryck; ett servicekonto har ingetdera. SSO- och HR-onboardingprocesser hanterar anställda, inte API-nycklar. Så NHI:er kringgår de starkaste mänskligt inriktade säkerhetskontrollerna.
2. Inget enhetligt lager: Varje plattform har sin egen autentiseringsuppgifterarkiv. AWS har IAM, GitHub har personliga åtkomsttokens, databaser har servicekonton, SaaS-plattformar har integrationstokens. Det finns vanligtvis ingen enhetlig vy över alla NHI:er. När personen som skapade en NHI byter roll eller slutar, finns autentiseringsuppgifterna kvar med fullständig åtkomst och ingen ägare. Forskning visade att 91 % av tidigare anställdas tokens förblir aktiva efter att de slutat.
3. Tillstånd hopar sig och granskas aldrig: NHI:er (National Infrastructure His) har vanligtvis bred åtkomst eftersom det är snabbare att konfigurera. Ingen granskar maskinbehörigheter kvartalsvis på samma sätt som åtkomstgranskningar riktar sig mot mänskliga konton. Studier visar att 97 % av NHI:er har alltför stora privilegier, och 88 % av organisationerna behandlar endast mänskliga konton som privilegierade, vilket helt missar attackytan för maskinidentitet.

NHI-hotmodell: Hur angripare utnyttjar maskinidentiteter

Attackscenario	Hur det fungerar	Varför NHI:er gör det enklare	Primär kontroll
Stöld av autentiseringsuppgifter från kodförråd	Angripare hittar API-nycklar eller tokens som är inlagda i ett offentligt eller privat kodarkiv	44 % av tokens hittas exponerade i kodcommits, ärenden och chattverktyg; ingen mänsklig lösenordshashning skyddar dem.	Hemlighetsskanning i CI/CD-pipelines; hemlighetshanterare istället för hårdkodade autentiseringsuppgifter; omedelbar rotation vid misstänkt exponering
Utnyttjande av föräldralösa konton	Angriparen upptäcker ett tjänstkonto eller en token som fortfarande är aktiv men som inte har någon nuvarande ägare, övervakning eller granskning.	91 % av tidigare anställdas tokens förblir aktiva; föräldralösa konton genererar inga beteendevarningar eftersom det inte finns någon baslinje	Automatiserad avveckling kopplad till applikationens livscykel; regelbundna rensningsskanningar tar bort icke-stereomikroskopiska infektioner utan aktuell användning eller ägare
Lateral förflyttning via överprivilegierade servicekonton	Angripare komprometterar ett tjänstkonto och använder dess breda behörigheter för att komma åt andra system	97 % av NHI:er har för många privilegier; ett enda komprometterat tjänstkonto kan nå produktionsdatabaser, hemlighetslager och administratörs-API:er	Minsta möjliga privilegium för varje NHI; just-in-time-åtkomst för upphöjda operationer; nätverkssegmentering som begränsar NHI-nåbarheten
Leveranskedjans attack via tredjepartsintegration	Ett komprometterat tredjepartsverktyg eller en SaaS-integration använder sina beviljade NHI-behörigheter för att komma åt organisationens data.	Tredjepartsintegrationer får NHI:er med beständig, bred åtkomst; organisationen kan inte granska tredje partens egen säkerhetsstatus.	Inventering av alla tredjeparts-NHI:er med åtkomstgranskningar; beviljade omfattningar till minimumkrav; återkalla integrationer som inte längre används aktivt
Utnyttjande av överprivilegier för AI-agenter	Angripare komprometterar eller manipulerar en AI-agent med administrativ åtkomst, vilket möjliggör dataexfiltrering i maskinhastighet	Agenter får ofta delegerade mänskliga inloggningsuppgifter eller bred åtkomst; CSA fann att 92 % av säkerhetspersonalen var oroade över AI-agentsäkerheten.	Tillämpa minsta möjliga privilegier för varje AI-agentidentitet; kräva mänsklig tillsyn för åtgärder med hög påverkan; möjlighet att inaktivera alla agenter omedelbart

NHI-riskkategorier: OWASP:s topp 10 över icke-mänskliga identiteter

År 2025 publicerade OWASP sin topp 10-lista över icke-mänskliga identiteter, där de största NHI-riskerna rankas efter påverkan. Listan ger branschens tydligaste prioriteringsramverk för NHI-säkerhetsprogram. Den största risken är felaktig offboarding (föräldralösa inloggningsuppgifter). Den fullständiga listan omfattar:

1. Felaktig offboarding: inloggningsuppgifter som förblir aktiva efter att tjänsten, projektet eller personen de tillhör har försvunnit.
2. Hemlig läckage: tokens och nycklar som hamnar i källkod, loggar, konfigurationsfiler eller chattverktyg.
3. Sårbar NHI från tredje part: integreringar med externa verktyg som ger NHI-åtkomst till din miljö.
4. Osäker autentisering: beroende av äldre eller svaga autentiseringsmekanismer för maskin-till-maskin-anslutningar.
5. Överprivilegierad NHI: tjänstkonton och tokens med mer åtkomst än vad deras funktion kräver.
6. Osäkra molndistributionskonfigurationer: statiska autentiseringsuppgifter i CI/CD-pipelines snarare än arbetsbelastningsidentitetsfederation.
7. Långlivade hemligheter: inloggningsuppgifter som aldrig går ut, vilket maximerar det fönster en angripare har om de blir stulna.
8. Miljöisolering: samma autentiseringsuppgifter som används i utvecklings-, test- och produktionsmiljöer.
9. NHI-återanvändning: samma identitet eller hemlighet som delas mellan olika tjänster eller komponenter.
10. Mänsklig användning av NHI: personer som använder servicekonton eller maskininloggningsuppgifter för manuella uppgifter, vilket suddar ut revisionsspåret.

Mönstret är konsekvent: nästan varje risk kan spåras tillbaka till hemligheter som lever för länge, för mycket privilegier och inget rent sätt att pensionera en identitet. Åtgärda dessa tre grundproblem så har du åtgärdat det mesta av listan. För en detaljerad uppdelning av varje risk och dess specifika åtgärder, se vårt tillhörande inlägg om de 10 största icke-mänskliga identitetsriskerna.

Hur man säkrar icke-mänskliga identiteter

1. Upptäck och inventera: Kör kontinuerliga skanningar över moln-, SaaS- och lokala system för att hitta varje NHI. Registrera var och en i en central inventering med en namngiven ägare. Utan insyn är ingen annan kontroll meningsfull.
2. Tillämpa lägsta privilegium: Ge varje NHI endast den åtkomst som dess specifika jobb kräver. Begränsa omfattningen till ett minimum: en specifik API-slutpunkt, en specifik S3-bucket, en specifik databastabell. Granska regelbundet och ta bort överflödiga behörigheter.
3. Ersätt långlivade hemligheter med kortlivade inloggningsuppgifter: Detta är den enskilt störst påverkande förbättringen. Den öppna SPIFFE-standarden (med sin SPIRE-referensimplementering) ger varje arbetsbelastning ett kortlivat kryptografiskt identitetsdokument (SVID) utfärdat som ett X.509-certifikat eller JWT, som roterar automatiskt (ofta varje timme som standard). Stulna SVID:er är värdelösa nästan omedelbart. NIST SP 800-207A rekommenderar uttryckligen SPIFFE för arbetsbelastningsidentitet i molnbaserade miljöer.
4. Använd just-in-time-åtkomst: bevilja behörigheter för en specifik uppgift och återkalla dem i det ögonblick uppgiften är klar. Ingen behörighet förblir inaktiv, vilket tar bort den permanenta åtkomst som angripare utnyttjar.
5. Automatisera avveckling: Att ta bort en tjänst eller applikation bör automatiskt utlösa återkallelse av dess tillhörande NHI:er. Koppla NHI-livscykeln till applikations- och projektlivscykeln på samma sätt som HR-offboarding utlöser avregistrering av mänskliga konton.
6. Övervaka NHI-beteendet kontinuerligt: Logga alla NHI-autentiserings- och åtkomsthändelser. Varna för avvikelser: en API-nyckel som autentiserar från en oväntad IP-adress, ett tjänstkonto som får åtkomst till en resurs som det aldrig har berört, en token som används utanför dess normala öppettider. Dessa är ofta de första indikatorerna på att autentiseringsuppgifter har komprometterats.

Varför detta är viktigt just nu år 2026

Två krafter gör NHI-säkerhet till en prioritet för 2026, inte en framtida situationsfaktor.

AI-agenter är redan måltavlor. Gartner förutspår att 25 % av företagsintrången år 2028 kommer att spåras tillbaka till missbruk av AI-agenter. Varje AI-agent är en NHI (National Influencer Healthcare). Att säkra maskinidentiteter är den grundläggande förutsättningen för att säkert distribuera de AI-verktyg som organisationer redan bygger. Riktlinjerna från maj 2026, som drivs av sex myndigheter (CISA, NSA och partners i Australien, Kanada, Storbritannien och Nya Zeeland) om noggrant införande av agentiska AI-tjänster, kräver åtkomst med lägsta möjliga behörighet, nätverkssegmentering och snabb inneslutningskapacitet för varje AI-agent, vilka alla är NHI-styrningskontroller.

Certifikatens livslängd krymper kraftigt. TLS-certifikat är maskinidentiteter, och från och med den 15 mars 2026 har publika TLS-certifikat en livslängd på högst 200 dagar (en minskning från 398). Detta sjunker till 100 dagar år 2027 och 47 dagar år 2029. Förnyelsevolymen vid 47 dagars livslängd är ungefär åtta gånger högre än vid 398 dagars livslängd. Manuell spårning och förnyelse kommer att misslyckas vid den frekvensen; automatiserad hantering av certifikatlivscykeln är inte längre valfritt. Observera att detta gäller publika TLS-certifikat; intern PKI sätter sina egna gränser, men det operativa trycket för att automatisera är identiskt.

Efterlevnaden kommer ikapp. NIST SP 800-207 (Zero Trust Architecture) kräver uttryckligen att maskinidentiteter styrs med samma rigorösa krav som mänskliga identiteter. PCI DSS 4.0-kraven 8.6.1 till 8.6.3, som är fullt verkställbara sedan mars 2025, kräver noggrann hantering av applikations- och systemkonton, förbud mot hårdkodade lösenord och skydd av tjänstkontouppgifter från missbruk.

Begränsningar och implementeringsutmaningar

• Kortlivade autentiseringsuppgifter kräver automatiseringsinfrastruktur: Att ersätta statiska hemligheter med SPIFFE/SPIRE eller molnbaserad arbetsbelastningsidentitet kräver att infrastrukturen för identitetsutfärdande distribueras och underhålls. Detta är en meningsfull investering men är rätt arkitektonisk riktning; alternativet (permanenta statiska hemligheter) skapar obegränsade exponeringsfönster.
• Äldre applikationer kanske inte stöder dynamisk inmatning av autentiseringsuppgifter: Vissa äldre applikationer läser inloggningsuppgifter från statiska konfigurationsfiler vid start och kan inte konfigureras om för att acceptera dynamiskt injicerade kortlivade inloggningsuppgifter utan kodändringar. Dessa applikationer kräver en migreringsplan snarare än ett omedelbart byte.
• Tredjeparts NHI:er ligger inte helt inom din kontroll: Du kan granska och omfånga de behörigheter du beviljar tredjepartsintegrationer, men du kan inte direkt styra hur tredje part hanterar autentiseringsuppgifterna från sin sida. Säkerhetsfrågeformulär för leverantörer och riskgranskningar av integrationer fyller delvis detta gap.
• Upptäckter sker pågående, inte engångsföreteelser: NHI:er skapas kontinuerligt genom automatisering. En engångssökning ger en ögonblicksbild vid en given tidpunkt; kontinuerlig skanning krävs för att hålla inventeringen aktuell eftersom nya autentiseringsuppgifter tillhandahålls dagligen av pipelines, orkestreringsplattformar och utvecklingsverktyg.

Hur krypteringskonsulting kan hjälpa

Certifikat är den maskinidentitetstyp som de flesta organisationer redan är beroende av i stor skala, och det är just de som nu exploderar i antal och krymper i giltighetstid. CertSecure Manager adresserar certifikatdimensionen av NHI-säkerhet direkt:

• Upptäckt och centraliserad inventering: CertSecure Manager upptäcker certifikat i molnbaserade, lokala och hybridsystem och konsoliderar dem till en enda inventering med ägartilldelning för varje certifikat. Tidigare okända eller ospårade certifikat dyker upp och ingår i styrningen.
• Automatisk förnyelse med noll kontakt: Certifikat förnyas automatiskt innan de löper ut. Med 47 dagars certifikatlivstid år 2029 är zero-touch-förnyelse inte en bekvämlighetsfunktion utan ett driftskrav; manuell förnyelse med den frekvensen kommer att orsaka avbrott.
• Policytillämpning och lägsta möjliga privilegier: Varje team hanterar endast sina egna certifikat; endast godkända algoritmer och nyckelstorlekar är tillåtna. Detta implementerar de lägsta privilegier och styrningskontroller som NHI-säkerhet kräver för certifikatinventeringen.
• Fullständig revisionslogg: Alla händelser i certifikatets livscykel loggas och uppfyller PCI DSS 4.0-kraven 8.6.1-8.6.3 och NIST SP 800-207-kraven för bevis för maskinidentitetsstyrning.

För den bredare NHI-styrningsbilden, inklusive tjänstekonton, API-nycklar, AI-agentuppgifter och krypteringsstrategi, bedömer våra krypteringsrådgivningstjänster var ni står idag och bygger en färdplan som täcker hela maskinidentitets- och krypteringsprogrammet, inte bara certifikat.

Slutsats

Icke-mänskliga identiteter är nu den största och snabbast växande identitetskategorin i företagsmiljöer, och AI-agenter accelererar den tillväxten. Styrningsgapet är strukturellt: mänskliga IAM-verktyg, MFA och HR-processer kan inte hantera maskinuppgifter. Attackytan som skapas av överprivilegierade, långlivade, oövervakade icke-mänskliga HI:er är en som angripare redan vet hur man utnyttjar.

Svaret är operativt enkelt: hitta varje NHI, tilldela den en ägare, begränsa dess behörigheter till vad den verkligen behöver, ge den kortlivade autentiseringsuppgifter som roterar automatiskt, övervaka dess beteende och pensionera den ordentligt när dess syfte upphör. De organisationer som gör detta rätt år 2026 kommer inte att vara de som reagerade på ett intrång – de kommer att vara de som gjorde maskinidentitet till en förstklassig styrningsfråga innan ett intrång inträffade. Om du vill bedöma din nuvarande NHI-position och bygga ett styrningsprogram som kan skalas, kontakta Encryption Consulting.

Vanliga frågor om partihandel med mat och dryck

Vad är en icke-mänsklig identitet (NHI)?

En NHI är en digital autentiseringsuppgift som används av programvara snarare än en person: API-nycklar, OAuth-tokens, tjänstkonton, TLS-certifikat, SSH-nycklar, moln-IAM-roller och AI-agentautentiseringsuppgifter. Programvara autentiserar med hemligheter snarare än lösenord och MFA-prompter. Maskinidentiteter är en närbesläktad term; NHI är den bredare kategorin som även omfattar AI-agenter och programvaru-till-programvaru-anslutningar.

Varför överväger icke-mänskliga identiteter mänskliga identiteter?

Tre krafter mångfaldigade dem: molnbaserade mikrotjänstarkitekturer som kräver en separat identitet per tjänst; automatisering som skapar autentiseringsuppgifter programmatiskt med snabbhet; och AI-agenter som var och en kräver sina egna autentiseringsuppgifter och driftsätts i miljontals exemplar. Maskinidentiteter överstiger mänskliga med 82 till 1 i typiska företag, och Gartner förväntar sig att detta förhållande kommer att öka.

Vad är styrningsgapet inom NHI-säkerhet?

Tre dimensioner: mänskliga kontroller som MFA och SSO gäller inte för maskiner; ingen enhetlig inventering finns över plattformar, så autentiseringsuppgifter ackumuleras utan en enda ägarvy; och NHI:er är kroniskt överprivilegierade eftersom bred åtkomst är snabbare att etablera och ingen granskar maskinbehörigheter. 97 % av NHI:er har alltför stora privilegier; 88 % av organisationerna klassificerar inte maskinkonton som privilegierade.

Vad är SPIFFE och hur hjälper det?

SPIFFE (Secure Production Identity Framework for Everyone) är en öppen standard som utfärdar ett kortlivat, kryptografiskt verifierbart identitetsdokument (SVID) för varje arbetsbelastning, utfärdat antingen som ett X.509-certifikat eller JWT, genom sin SPIRE-implementering. SVID:er roterar automatiskt (vanligtvis varje timme), så stulna autentiseringsuppgifter upphör att gälla nästan omedelbart. NIST SP 800-207A rekommenderar uttryckligen SPIFFE för molnbaserad arbetsbelastningsidentitet.

Varför krymper livslängden för TLS-certifikat och vad innebär det för NHI-hantering?

CA/Browser Forum föreskrev minskningar: maximalt 200 dagar från mars 2026, 100 dagar år 2027, och 47 dagar år 2029. Vid 47 dagars livslängd är förnyelsevolymen ungefär åtta gånger högre än vid 398 dagars livslängd. Manuell hantering misslyckas vid den frekvensen; automatiserad hantering av certifikatlivscykeln krävs. TLS-certifikat är maskinidentiteter, så detta är ett NHI-styrningsproblem, inte bara ett IT-driftsproblem.

Vilka är de viktigaste kontrollerna för att säkra icke-mänskliga identiteter?

Kontinuerlig identifiering och inventering med namngivna ägare; lägsta möjliga behörighetsnivå för alla NHI-behörigheter; ersättning av statiska långlivade hemligheter med kortlivade automatiskt roterande autentiseringsuppgifter (SPIFFE, molnarbetsbelastningsidentitet, certifikatautomation); just-in-time-åtkomst för förhöjda operationer; automatiserad avveckling kopplad till applikationslivscykel; och beteendeövervakning med avvikelsevarningar.