PAM och break-glass-konton för ISO 27001 år 2026

Klockan 02:14 en söndagsmorgon får incidentledaren meddelandet som varje informationssäkerhetschef fruktar: ”Autentisering i produktion fallerar. Administrationskonsolen går inte att nå. Databasens failover har fastnat.”

Molningenjören i beredskap kan se problemet, men kan inte åtgärda det. Den normala privilegierade rollen är beroende av samma identitetsleverantör som nu har nedsatt funktion. Driftansvarig begär nödautentiseringsuppgiften för administratören. Den regelefterlevnadsansvariga frågar om break-glass-kontot någonsin har testats. Dataskyddsombudet frågar om åtkomst till produktionsdatabasen kan exponera personuppgifter. Informationssäkerhetschefen ställer frågan som avgör om detta blir en kontrollerad återställning eller en revisionsmardröm:

”Kan vi bevisa vem som använde nödåtkomsten, varför den användes, vad personen gjorde och att kontot återställdes efteråt?”

En annan organisation kan ställas inför samma problem i ett tystare rum. En informationssäkerhetschef på ett fintech-bolag sitter mittemot externa revisorer efter en felkonfiguration i en molndatabas. Incidenten åtgärdades snabbt, men grundorsaken var inte betryggande. En tredjepartsutvecklare hade stående administrativa privilegier. När den primära administratören inte var tillgänglig använde utvecklaren ett break-glass-konto baserat på ett delat lösenord som lagrades i en ”säker” anteckning tillgänglig för DevOps-teamet.

Revisorerna fokuserade inte enbart på felkonfigurationen. De frågade om åtkomsten var tidsbegränsad, om individuellt ansvar och spårbarhet fanns, om kommandon loggades, om personuppgifter skyddades enligt GDPR Article 32, om DORA-kraven för IKT-risk var uppfyllda och om NIS2-förväntningarna på cyberhygien kunde styrkas.

Det är den praktiska brytpunkten för privilegierad åtkomsthantering och break-glass-konton under 2026. PAM är inte längre ett avgränsat projekt inom identitetssäkerhet. Det är där ransomware, kompromettering i molnmiljö, leverantörsrisk, dataskydd, operativ resiliens och revisionsbevis möts.

Privilegierad åtkomst är där angripare försöker vinna. Break-glass-åtkomst är där försvarare försöker återställa. Båda bygger på samma riskfyllda förmåga: förhöjd åtkomst som kan kringgå kontroller, ändra konfigurationer, läsa känsliga data, rotera nycklar, inaktivera loggning, återställa säkerhetskopior, driftsätta kod eller förstöra bevismaterial.

Clarysecs praktiska ståndpunkt är enkel: nödåtkomst är nödvändig, men ostyrd nödåtkomst är ostyrd risk. Rätt svar är inte ”inga break-glass-konton”. Rätt svar är en styrd modell för privilegierad åtkomsthantering med inventering, godkännande, tidsbegränsning, stark autentisering, sessionsloggning, granskning efter användning, återställning av autentiseringsuppgifter och revisionsbevis.

Varför privilegierad åtkomst är en efterlevnadsfråga på styrelsenivå

I miljöer med lägre mognad behandlas privilegierad åtkomst ofta som en IT-administrativ uppgift. Någon behöver administratörsrättigheter, ett ärende öppnas, en roll tilldelas och verksamheten går vidare. Den modellen håller inte för modern ransomware, molnbaserad infrastruktur, ansvar enligt NIS2, operativ resiliens enligt DORA eller granskning av incidenter enligt GDPR.

NIS2-direktivet flyttar cybersäkerhetsstyrning in i styrelserummet. Article 20 kräver att ledningsorgan hos väsentliga och viktiga entiteter godkänner riskhanteringsåtgärder för cybersäkerhet, övervakar genomförandet och genomgår cybersäkerhetsutbildning. Article 21 kräver lämpliga och proportionella tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, kontrolleffektivitet, cyberhygien, HR-säkerhet, åtkomstkontroll, tillgångshantering och MFA eller kontinuerlig autentisering där det är lämpligt.

För SaaS-leverantörer, leverantörer av hanterade tjänster, leverantörer av hanterad säkerhet, molntjänster, datacenter och andra organisationer inom digital infrastruktur beror NIS2-tillämpligheten på sektor, storlek, roll, gränsöverskridande påverkan och etablering i EU. Den operativa lärdomen är tydlig: åtkomstkontroll är inte längre gömd i en teknisk bilaga. Den ingår i den baslinje för cyberhygien som ledningen ska godkänna, övervaka och korrigera.

För finansiella entiteter ändrar Digital Operational Resilience Act språket, men inte den underliggande risken. DORA gäller från den 17 januari 2025 och etablerar ett enhetligt ramverk för IKT-riskhantering, rapportering av större IKT-relaterade incidenter, testning av digital operativ resiliens och riskhantering för IKT-tredjeparter. Article 5 kräver styrnings- och kontrollarrangemang för IKT-risk, där ledningsorganet definierar, godkänner, övervakar och ansvarar för arrangemangen för IKT-risk. Article 6 kräver ett dokumenterat ramverk för IKT-riskhantering med policyer, rutiner, protokoll och verktyg för att skydda IKT-tillgångar. Article 17 kräver en process för hantering av IKT-relaterade incidenter som upptäcker, registrerar, klassificerar, eskalerar och återställer säker drift.

GDPR tillför perspektivet dataskydd och ansvarsskyldighet. Article 5(1)(f) kräver att personuppgifter behandlas med integritet och konfidentialitet. Article 5(2) kräver ansvarsskyldighet. Article 25 kräver inbyggt dataskydd och dataskydd som standard. Article 32 kräver lämpliga tekniska och organisatoriska åtgärder för säkerhet i behandlingen. Om en privilegierad användare kan exportera kundregister, komma åt särskilda kategorier av personuppgifter, inaktivera revisionsloggar eller ändra inställningar för bevarande utan granskning har organisationen inte enbart gjort ett IAM-misstag. Den kan sakna förmåga att visa lämplig säkerhet.

ISO/IEC 27001:2022 är ledningssystemets ryggrad som gör det möjligt att hantera dessa skyldigheter i ett integrerat program. Clause 4.2 kräver att organisationen förstår intressenter och deras krav, inklusive rättsliga, regulatoriska och avtalsmässiga skyldigheter. Clause 5.1 kräver ledarskap och åtagande. Clause 6.1.2 kräver informationssäkerhetsriskbedömning. Clause 6.1.3 kräver riskbehandling. Clause 8 kräver operativ planering och styrning.

För privilegierad åtkomst flyttar detta samtalet från ”vilket PAM-verktyg ska vi köpa?” till ”vilka risker behandlar vi, vilka kontroller har valts, vem äger dem, hur används de och vilket underlag visar att de fungerar?”

PAM är inte en enskild kontroll, utan en beviskedja

Ett PAM-verktyg kan lagra lösenord i valv, förmedla sessioner, spela in tangenttryckningar, rotera autentiseringsuppgifter och genomdriva just-in-time-åtkomst. Dessa förmågor är viktiga. Men om organisationen inte har definierat privilegierade roller, godkänt nödåtkomst, mappat åtkomst till tillgångar, granskat rättigheter, skyddat loggar och utbildat administratörer blir verktyget en partiell kontroll med svag försvarbarhet vid revision.

Det mest användbara sättet att styra privilegierad åtkomst är att tänka i kontrollresultat, inte i verktygsnamn.

Zenith Controls: The Cross-Compliance Guide Zenith Controls behandlar ISO/IEC 27002:2022 kontroll 8.2, Privilegierade åtkomsträttigheter, som tyngdpunkten för PAM. Den klassificerar kontrollen som förebyggande, stödjande för konfidentialitet, riktighet och tillgänglighet, anpassad till cybersäkerhetskonceptet Protect, den operativa förmågan Identity and access management och säkerhetsdomänen Protection.

Kontroll 8.2 är kraftfull eftersom den kopplas till de omgivande kontroller som gör privilegierad åtkomst möjlig att granska:

Därför stannar en revisor sällan vid frågan: ”Har ni ett PAM-system?” De starkare revisionsfrågorna är: Har ni en förteckning över privilegierade konton? Är privilegierade roller godkända? Är rättigheterna tidsbegränsade? Är nödautentiseringsuppgifter säkrade? Kan ni visa vem som använde dem? Loggas kommandon? Ingår leverantörsadministratörer? Granskas åtkomsträttigheter? Återställdes autentiseringsuppgifterna? Har undantag riskaccepterats?

Åtkomsträttsmappningen i Zenith Controls gör detta tydligt: hantering av åtkomsträttigheter operationaliserar åtkomstkontrollprinciper såsom principen om minsta privilegium, need-to-know-principen och auktorisering, medan privilegierade konton kräver särskild granskning och snabb återkallelse när de inte längre behövs.

Policykrav för tillförlitlig break-glass-åtkomst

Ett break-glass-konto är inte ett delat administratörslösenord i ett förseglat kuvert. År 2026 är den modellen för svag för moln, fintech, SaaS, hälso- och sjukvård, hanterade tjänster och reglerad digital drift.

En försvarbar break-glass-modell behöver sju minimikrav i policyn:

1. Kontot ska vara dokumenterat.
2. Kontot ska vara godkänt.
3. Användning ska kunna hänföras till en unik person där det är tekniskt möjligt.
4. Användning ska begränsas till verkliga nödsituationer.
5. Användning ska loggas och granskas.
6. Autentiseringsuppgifter eller autentiseringsfaktorer ska återställas eller roteras efter användning.
7. Kontot ska testas och ingå i revisionsomfattningen.

Clarysecs policybibliotek omsätter dessa principer till användbart styrningsspråk.

Policy för hantering av användarkonton och privilegier – SME Policy för hantering av användarkonton och privilegier – SME anger:

”Nödåtkomst, t.ex. administratörskonton för ”break glass”, ska vara tydligt dokumenterad, säkrad och användas endast när det är absolut nödvändigt.”

Från avsnittet ”Riskbehandling och undantag”, policyklausul 7.3.1.

Samma SME-policy fortsätter:

”Sådana konton ska loggas, granskas efter användning och återställas efter varje nödhändelse.”

Från avsnittet ”Riskbehandling och undantag”, policyklausul 7.3.2.

För privilegiehöjning i den dagliga driften kräver SME-policyn även:

”Förhöjda eller administrativa privilegier kräver ytterligare godkännande av verkställande chef eller IT-ansvarig och ska vara dokumenterade, tidsbegränsade och föremål för periodisk granskning.”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.2.2.

För större organisationer går företagspolicyn längre. Policy för hantering av användarkonton och privilegier Policy för hantering av användarkonton och privilegier kräver att:

”Privilegierade sessioner ska loggas fullständigt, inklusive utfärdade kommandon och utförda åtgärder. Loggar ska granskas periodiskt av utsedda granskare.”

Från avsnittet ”Krav för genomförande av policyn”, policyklausul 6.4.2.

Samma policy kräver att tillfälliga eller privilegierade nödkonton följer en dokumenterad break-glass-procedur i klausul 6.2.5, medan klausul 7.4 beskriver kraven för den proceduren.

Åtkomstkontrollpolicy Åtkomstkontrollpolicy förstärker kraven på bevarande inför revision:

”Godkännandebeslut ska loggas och bevaras för revisionsändamål i minst 2 år.”

Från avsnittet ”Styrningskrav”, policyklausul 5.3.2.

Loggnings- och övervakningspolicy – SME Loggnings- och övervakningspolicy – SME anger förväntningar på autentiseringsloggning:

”Autentiseringsloggar: lyckade och misslyckade inloggningsförsök, sessionslängd, MFA-användning”

Från avsnittet ”Styrningskrav”, policyklausul 5.4.2.

Tillsammans förvandlar dessa klausuler nödåtkomst från en heroisk nödlösning till en kontrollerad händelse. Kontot är exceptionellt, men styrningen är det inte.

Zenith Blueprints metod för att införa PAM

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandlar privilegierad åtkomst som ett praktiskt införandeproblem, inte som ett teoretiskt kontrolluttalande. I fasen Controls in Action, Step 19, Technological Controls I, anges:

”I varje informationssystem är privilegierad åtkomst makt, och med den makten följer risk.”

Från fasen Controls in Action, Step 19: Technological Controls I.

Step 19 kräver att organisationer identifierar privilegierade konton i lokala miljöer, moln, SaaS, utvecklingsmiljöer och infrastrukturmiljöer. Det omfattar domänadministratörer, root-användare, administratörer av molntenanter, databassuperanvändare och styrande konton för CI/CD-pipelines. Det betonar också minimering av privilegierad åtkomst genom rollbaserad åtkomstkontroll, just-in-time-privilegiehöjning och godkännandearbetsflöden.

Det är viktigt eftersom många allvarliga incidenter inte börjar med det formella break-glass-kontot. De börjar med stående privilegier. En molningenjör behåller ägarrättigheter ”för säkerhets skull”. En databasadministratör behåller produktionsåtkomst efter teambyte. Ett CI/CD-tjänstekonto har breda behörigheter över flera miljöer. Ett konto hos en leverantör av hanterade tjänster undantas från MFA eftersom ”de behöver snabb åtkomst”.

Step 20 i Zenith Blueprint utvidgar samma resonemang till privilegierade verktyg. Den instruerar organisationer att skapa eller uppdatera en förteckning över privilegierade verktyg, begränsa körning till behöriga administratörer, verifiera att användning loggas och genererar larm samt överväga skriptloggning, till exempel PowerShell-loggning via gruppolicy. Detta är kritiskt eftersom ett privilegierat konto ofta bara är ingångspunkten. Skadan uppstår när angriparen kör verktyg som inaktiverar kontroller, dumpar autentiseringsuppgifter eller förflyttar sig lateralt.

Step 22 formaliserar livscykeln för åtkomstkontroll. Den kräver strukturerad åtkomsttilldelning och avprovisionering, helst integrerad med HR och stödd av arbetsflöden för åtkomstbegäran, med dokumenterade åtkomstgranskningar kvartalsvis. Step 16 kopplar livscykeln till offboarding genom att kräva en avslutningschecklista för anställda som HR och IT använder gemensamt, inklusive inaktivering av konton, återlämning av tillgångar och påminnelser om sekretessavtal.

Zenith Blueprint gör PAM till en sammanhängande operativ modell: identitet, HR, privilegierade verktyg, loggning, incidentrespons, åtkomstgranskningar och revisionsbevis förstärker varandra.

En praktisk styrningsmodell för break-glass 2026

En väl utformad break-glass-process måste fungera under störning. Om den är beroende av samma identitetsleverantör, ärendeplattform och chattjänst som är otillgängliga under avbrottet är den bara teater.

Samtidigt får nödåtkomst inte bli en genvägskanal för bekvämlighet. Clarysec utformar normalt break-glass-styrning kring fyra lager: förebyggande, aktivering, observation och återställning.

För molnmiljöer ska detta omfatta administratörer på tenantnivå, root-konton i moln, nödkonton hos identitetsleverantörer, privilegierade tjänstekonton, databasmasteranvändare, Kubernetes-roller med cluster-admin, CI/CD-driftsättningsnycklar, administratörer av hemlighetsvalv och tredjepartssupportkonton.

För hybridmiljöer ska detta omfatta domänadministratörer, administratörer för säkerhetskopiering, hypervisoradministratörer, brandväggsadministratörer, EDR-konsoladministratörer och användare av privilegierade verktyg.

För integritetskänsliga miljöer ska detta omfatta administratörer som kan komma åt databaser med personuppgifter, loggar med identifierare, HR-register, biometriska data för identitetsverifiering, system för bedrägeriövervakning eller kundsupportverktyg.

Målbilden är enkel att beskriva och svår att fejka: varje nödväg är känd, godkänd, säkrad, observerbar, reversibel och granskad.

En 60-minutersövning för break-glass-underlag

En informationssäkerhetschef eller regelefterlevnadsansvarig kan genomföra en användbar break-glass-övning redan denna vecka utan att köpa ett nytt verktyg. Målet är inte bara att bekräfta att kontot fungerar. Målet är att visa att kontrollen producerar underlag.

Scenario

Anta att den primära identitetsleverantören har nedsatt funktion. Normal just-in-time-privilegiehöjning är inte tillgänglig. Ett produktionskluster för databaser behöver akuta konfigurationsändringar för att återställa tjänsten. Break-glass-kontot för molnadministratör måste aktiveras.

Steg 1: Bekräfta att kontot finns i förteckningen över privilegierade konton

Använd Zenith Blueprint, fasen Controls in Action, Step 19, för att validera att kontot finns i förteckningen över privilegierade konton. Registrera kontonamn och miljö, verksamhetsägare, teknisk ägare, nåbara system, påverkan på personuppgifter, autentiseringsmetod, valvplats, rotationsmetod och senaste testdatum.

Om kontot saknas ska det behandlas som en kontrollbrist och läggas till i riskregistret.

Steg 2: Kontrollera policyanpassning

Mappa händelsen mot kraven i Policy för hantering av användarkonton och privilegier på dokumenterade break-glass-procedurer och loggning av privilegierade sessioner. Om ni är ett SME ska klausulerna 7.3.1 och 7.3.2 i Policy för hantering av användarkonton och privilegier – SME användas som lägsta baslinje: dokumenterad, säkrad, nödvändig, loggad, granskad och återställd.

Mappa bevarande av godkännanden mot Åtkomstkontrollpolicy klausul 5.3.2, som kräver att godkännandebeslut loggas och bevaras i minst 2 år.

Steg 3: Öppna en nödåtkomstpost

Skapa ett ärende eller en incidentpost före eller vid aktivering. Inkludera:

• Orsak till nödsituationen
• Påverkad tjänst
• Begärt konto
• Beställare
• Godkännare
• Starttid
• Förväntad sluttid
• Kundpåverkan eller regulatorisk påverkan
• GDPR-påverkan på personuppgifter
• Bevakningsflagga för NIS2- eller DORA-rapportering

Vänta inte till slutet med att återskapa händelseförloppet. Revisionsvärdet är starkast när posten börjar innan åtkomsten används.

Steg 4: Aktivera och observera

Aktivera break-glass-kontot. Bekräfta att MFA eller kompenserande autentisering används, att sessionen spelas in, att kommandon eller administrativa åtgärder loggas, att loggar vidarebefordras till centraliserad loggning, att tidssynkronisering stödjer rekonstruktion av tidslinjen och att ett larm genereras vid användning av nödkontot.

Detta ligger i linje med Zenith Controls för 8.15 Loggning, som beskriver loggning som det grundläggande datalagret för övervakning och noterar att privilegierade användare och körning av privilegierade verktyg ska loggas heltäckande.

Steg 5: Stäng, återställ och granska

Efter nödåtgärden ska kontot inaktiveras eller återföras till förseglad status, autentiseringsuppgifter roteras eller autentiseringsfaktorn återställas, sessionsloggar granskas, kommandon och konfigurationsändringar dokumenteras, det bekräftas att ingen onödig dataåtkomst skedde, incidentposten uppdateras, erfarenhetsåterföring dokumenteras och beslut fattas om trösklar för anmälan enligt NIS2, DORA eller GDPR har utlösts.

Om personuppgifter har åtkommits ska dataskyddsombudet involveras. Om händelsen orsakade tjänstestörning eller kan orsaka väsentlig påverkan ska ansvarig för NIS2- eller DORA-rapportering involveras. Om break-glass-kontot inte fungerade ska det dokumenteras som en iakttagelse om operativ resiliens, inte enbart som ett IAM-problem.

Tvärgående efterlevnadsmappning för PAM- och break-glass-kontroller

Den starkaste styrningsmodellen duplicerar inte kontroller för varje regelverk. Den bygger en beviskedja som stödjer flera skyldigheter.

NIST CSF 2.0 är särskilt användbart när PAM översätts till en Current Profile och Target Profile. Profilmetoden börjar med omfattning och samlar därefter in policyer, riskprioriteringar, register, krav, praxis och arbetsroller innan en prioriterad handlingsplan skapas. För privilegierad åtkomst innebär det att profilen avgränsas kring identitetssäkerhet, molnadministration, ransomware-resiliens, kritiska finansiella system eller leverantörsåtkomst.

För finansiella entiteter som omfattas av DORA fungerar DORA som EU:s sektorsspecifika cyberresiliensregim för motsvarande risk- och incidentskyldigheter enligt NIS2. Det gör inte NIS2 irrelevant. Det innebär att den finansiella entiteten bör använda DORA som styrande regelverk för IKT-risk och incidentkrav, samtidigt som samordning upprätthålls med nationella cybersäkerhetsstrategier, behöriga myndigheter och CSIRT:er där det är tillämpligt.

Hur revisorer testar underlag för privilegierad åtkomst

Revisorer bedömer inte PAM enbart genom att läsa policy. De triangulerar policy, konfiguration, loggar, ärenden, intervjuer och observerad praxis.

Revisionsmetodiken i Zenith Controls för privilegierade åtkomsträttigheter hänvisar till revisionspraxis enligt ISO/IEC 19011:2018. Revisorer granskar policyer som definierar förhöjda rättigheter, rutiner för åtkomsttilldelning, övervakning och återkallelse. De granskar förteckningar över användarkonton, poster över privilegietilldelning och loggar. De bekräftar underlag genom intervjuer, PAM-verktyg, katalogtjänster och loggstickprov.

För åtkomsträttigheter noterar Zenith Controls att revisorer tar stickprov på användares åtkomstbegäran, verifierar dokumenterade godkännanden och bekräftar att IT endast tilldelade godkänd åtkomst. De jämför också användarroller med faktiska rättigheter och kontrollerar om principen om minsta privilegium efterlevs. För loggning inspekterar revisorer loggningens omfattning, händelsetyper, bevarandetider, skydd och faktiska loggposter. De bedömer om misslyckade inloggningar, åtkomst till känsliga data och konfigurationsändringar fångas och granskas.

Ett bra underlagspaket för break-glass omfattar:

• Godkänd begäran om nödåtkomst
• Incident- eller avbrottskontext
• Identitet för användaren som aktiverar åtkomst
• Godkännarens identitet
• Start- och sluttid
• MFA- eller autentiseringsunderlag
• Sessionsinspelning eller kommandologg
• Systemloggar och SIEM-larm
• Genomförda ändringar
• Bekräftelse på återställning av autentiseringsuppgifter
• Granskning efter användning
• Bedömning av dataåtkomst
• Bedömning av regulatorisk anmälningsskyldighet
• Korrigerande åtgärder om något fallerade

Om er övning inte kan producera detta paket är kontrollen inte revisionsklar.

Det dolda felet: privilegierad tredjepartsåtkomst

Många organisationer styr anställda administratörer bättre än leverantörsadministratörer. För moln, SaaS, fintech och miljöer med hanterade tjänster är det bakvänt.

NIS2 Article 21 omfattar säkerhet i leveranskedjan och relationer med direkta leverantörer och tjänsteleverantörer. DORA Articles 28 till 30 går längre för finansiella entiteter och kräver strategi för risker kopplade till IKT-tredjeparter, register över IKT-tjänsteavtal, leverantörsgranskning, bedömning av koncentrationsrisk, revisionsrätt, rätt att säga upp avtalet, exitstrategier och avtalsmässiga säkerhetsåtgärder.

Privilegierad leverantörsåtkomst ska ingå i PAM-omfattningen om leverantören kan administrera produktion, stödja kritiska eller viktiga funktioner, komma åt personuppgifter, ändra säkerhetskonfigurationer, hantera säkerhetskopior, driftsätta kod eller driva övervakningsverktyg.

Clarysec förväntar sig normalt att kontroller för privilegierad leverantörsåtkomst omfattar:

• Namngivna leverantörsanvändare, inte delade leverantörskonton
• Avtalsmässiga säkerhetskrav för privilegierad åtkomst
• MFA och säker fjärråtkomst
• Tidsbegränsade åtkomstfönster
• Kundgodkännande för nödåtkomst
• Sessionsloggning eller likvärdiga revisionsspår
• Omedelbar återkallelse när personal förändras
• Skyldigheter att samarbeta vid incidenter
• Bevarande av underlag anpassat till kundens revisionsbehov
• Exitplan för att ta bort leverantörsåtkomst

NIST CSF 2.0-resultat för leveranskedjan passar väl här. De efterfrågar leverantörsroller och ansvar, prioritering av leverantörer efter kritikalitet, krav i avtal, leverantörsgranskning, löpande övervakning, leverantörers medverkan i incidentplanering och riskplaner efter avtalets upphörande.

Om ett konto hos en leverantör av hanterade tjänster är undantaget från ert interna PAM-arbetsflöde är det inte en bekvämlighet. Det är ett högriskundantag som hör hemma i riskregistret, leverantörsregistret och åtkomstgranskningen.

Vanliga PAM- och break-glass-iakttagelser 2026

I Clarysecs uppdrag är iakttagelserna sällan överraskande. De är vanligtvis kombinationer av goda avsikter, operativt tryck och ofullständigt underlag.

De vanligaste iakttagelserna är:

• Break-glass-konton finns men är inte upptagna i förteckningen över privilegierade konton.
• Nödkonton är undantagna från normala åtkomstgranskningar.
• Organisationen kan inte bevisa vem som använde ett nödkonto.
• Kontot återställdes inte efter användning.
• Privilegierade sessioner loggas, men kommandon loggas inte.
• Loggar finns lokalt men skyddas inte från privilegierade användare.
• Root-konton i moln testas inte.
• Processer för MFA-återställning är odokumenterade.
• Privilegierad åtkomst för CI/CD-pipelines och tjänstekonton ignoreras.
• Tredjepartssupportåtkomst kringgår internt godkännande.
• Åtkomstgodkännande finns i chattmeddelanden men bevaras inte som revisionsbevis.
• Offboarding tar bort e-post och VPN men inte administratörsrättigheter i SaaS.
• Dataskyddsombudet involveras inte när privilegierad åtkomst kan exponera personuppgifter.
• Incidentåtgärdsplaner innehåller inte beslutspunkter för anmälan enligt NIS2, DORA eller GDPR.

Varje iakttagelse kan hanteras genom riskbehandling enligt ISO/IEC 27001:2022. Identifiera risken, tilldela en ägare, välj kontroller, uppdatera tillämpbarhetsförklaringen, genomför riskbehandlingsplanen och bevara dokumenterat underlag. Det är styrkan i att använda ett ISMS i stället för en splittrad uppsättning säkerhetsuppgifter.

Så ser god praxis ut

En mogen operativ modell för PAM och break-glass har fem återkommande rutiner.

För det första: inventera privilegierad åtkomst månadsvis eller kontinuerligt. Inkludera mänskliga administratörer, tjänstekonton, nödkonton, molnroller, CI/CD-identiteter, databasanvändare, privilegierade verktyg och tredjepartsadministratörer.

För det andra: tillämpa principen om minsta privilegium genom roller, just-in-time-privilegiehöjning och godkännanden. Stående privilegier ska vara sällsynta, motiverade och granskas oftare än standardanvändares åtkomst.

För det tredje: övervaka privilegierat beteende. Logga autentisering, sessionslängd, MFA-användning, kommandon, konfigurationsändringar, dataexporter, misslyckade försök, privilegiehöjning och körning av privilegierade verktyg.

För det fjärde: testa break-glass-konton före nödsituationen. Ett break-glass-konto som aldrig har testats är ett antagande, inte en kontroll.

För det femte: rapportera till ledningen. Både NIS2 och DORA lyfter cybersäkerhet och IKT-risk till ledningsorganets ansvar. Styrelsen behöver inte varje kommandologg, men den behöver mätetal: antal privilegierade konton, försenade granskningar, nödaktiveringar, leverantörsadministratörskonton, misslyckade tester, kritiska undantag och åtgärdsstatus.

Det är här Clarysecs verktygslåda blir praktisk. Policybiblioteket ger styrningsspråket. Zenith Blueprint ger införandesekvensen. Zenith Controls ger tvärgående efterlevnadsmappning, kontrollrelationer, stödjande standarder och revisionsmetodik.

Nästa steg: gör nödåtkomst till revisionsklar resiliens

Om er organisation inte har testat break-glass-åtkomst under de senaste 90 dagarna, börja där. Börja inte med en workshop om verktygsval. Börja med underlag.

1. Skapa eller uppdatera er förteckning över privilegierade konton.
2. Identifiera varje break-glass-konto och varje väg för nödadministration.
3. Mappa varje konto till verksamhetsägare, systemägare och datapåverkan.
4. Bekräfta policytäckning med Clarysecs Policy för hantering av användarkonton och privilegier Policy för hantering av användarkonton och privilegier eller Policy för hantering av användarkonton och privilegier – SME Policy för hantering av användarkonton och privilegier – SME.
5. Använd Zenith Blueprint Zenith Blueprint, fasen Controls in Action, Steps 19, 20, 22 och 16, för att koppla samman privilegierad åtkomst, privilegierade verktyg, livscykelgranskningar och offboarding.
6. Använd Zenith Controls Zenith Controls för att mappa ISO/IEC 27002:2022 kontroller 8.2, 5.18 och 8.15 mot förväntningar på underlag enligt NIS2, DORA, GDPR och NIST.
7. Genomför en break-glass-övning för underlag och registrera resultaten.
8. Lägg till luckor i riskbehandlingsplanen och följ upp åtgärder till stängning.

Privilegierad åtkomst är makt. Break-glass-åtkomst är nödmakt. År 2026 kommer de organisationer som återhämtar sig rent från ransomware, molnavbrott och identitetsfel att vara de som kan visa att nödåtkomst var kontrollerad före, under och efter krisen.

Clarysec kan hjälpa er att bygga det beviset, från policy till kontrollmappning och revisionsklart underlag. Börja med Zenith Blueprint, kombinera den med Policy för hantering av användarkonton och privilegier och Åtkomstkontrollpolicy, och använd sedan Zenith Controls för att visa hur ert PAM-program stödjer ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT 2019.