NDES och SCEP förklarade: Ryggraden i automatiserad certifikatregistrering

I takt med att organisationer alltmer använder sig av Zero Trust, enhetsautentisering och molnhanterad infrastruktur, är traditionell manuell certifikatregistrering inte längre skalbar. Oavsett om det gäller att installera tusentals bärbara datorer via Intune, utfärda certifikat för VPN-åtkomst eller aktivera Wi-Fi-autentisering över globala kontor, är automatiserad certifikatregistrering avgörande.

Det är här SCEP (Simple Certificate Enrollment Protocol) och NDES (Network Device Enrollment Service) spelar en avgörande roll i Microsofts PKI-ekosystem. Trots deras betydelse distribuerar många administratörer dem utan att helt förstå hur de fungerar, hur de skiljer sig från varandra eller hur man säkrar dem ordentligt. Felkonfigurerade NDES-servrar är fortfarande en av de vanligaste PKI- svagheterna som upptäcks under säkerhetsrevisioner.

Snabbt svar: Vad är NDES och SCEP?

SCEP (Simple Certificate Enrollment Protocol) är protokollet som tillåter enheter att begära certifikat via HTTP/HTTPS utan att ansluta till Active Directory. NDES (Network Device Enrollment Service) är Microsofts implementering av SCEP, som fungerar som en brygga mellan SCEP-talande enheter och ADCS. Utan NDES kan Intune- och MDM-plattformar inte utfärda certifikat från en lokal certifikatutfärdare.

Key Takeaways

• NDES är den nödvändiga bryggan mellan SCEP-talande enheter (Intune-hanterade slutpunkter, IoT-enheter, VPN-gatewayer, nätverksapparater) och Microsoft ADCS. Utan NDES kan dessa enheter inte hämta certifikat från en lokal certifikatutfärdare.
• Felkonfigurerade NDES-servrar är en av de vanligaste PKI-attackytorna. En internet-exponerad NDES-slutpunkt, ett överprivilegierat tjänstkonto eller en svag certifikatmall kan var för sig leda till obehörig certifikatutfärdande.
• Enligt DigiCerts Trust Pulse Survey (2 juli 2025) upplevde nästan hälften av alla företag certifikatrelaterade driftstopp under det senaste året. En felkonfigurerad eller otillgänglig NDES-server bryter enhetsautentiseringen i en hel organisation samtidigt.
• CA/Browser Forums omröstning SC-081v3 (april 2025) minskar den maximala giltighetstiden för offentliga TLS-certifikat till 47 dagar senast i mars 2029. Detta gör automatiserad SCEP/NDES-registrering och CLM-verktyg avgörande; manuell förnyelse kan inte stödja denna takt i enhetsflottans skala.
• SCEP och NDES ersätts inte av ACME; de har olika användningsområden. SCEP/NDES hanterar enhetscertifikat för Intune, VPN och nätverksapparater. ACME hanterar server- och arbetsbelastningscertifikat för DevOps-pipelines, Kubernetes och molnbaserade tjänster. De flesta företag behöver båda.

Vem borde bry sig om NDES och SCEP

NDES-distribution och säkerhet är ett tvärfunktionellt ansvar. Varje roll nedan har en direkt inverkan på att det blir rätt.

Roll	Varför det gäller	Åtgärdsobjekt
PKI-administratörer	Egen NDES-serverdistribution, konfiguration av certifikatmall för SCEP, installation av CA-registreringsagent och tillämpning av CA-policy för NDES-utfärdade certifikat	Distribuera NDES på en dedikerad server (inte CA); konfigurera mallar med korrekt nyckelanvändning, EKU och inga exporterbara privata nycklar; integrera CA-utgivningsloggar med SIEM
Säkerhetsarkitekter	Äga nätverksisoleringsdesignen, IIS-härdningsstandarder och NDES-tjänstkontoprivilegiemodellen som bestämmer attackytan för NDES-distributionen.	Placera NDES i en DMZ bakom en omvänd proxy eller applikationsgateway; tillämpa lägsta behörighet för NDES-tjänstkontot; definiera ACL:er för certifikatmallar som begränsar SCEP-registrering till auktoriserade enheter
Plattforms-/slutpunktsteam	Äg Intune-, MDM- och enhetshanteringsintegrationen som är beroende av NDES för certifikatleverans till hanterade enheter	Konfigurera Intune SCEP-profiler som pekar mot NDES HTTPS-slutpunkt; testa certifikatleverans till enhetstyper (Windows, iOS, Android, macOS); bekräfta att enhetens förtroendearkiv inkluderar den utfärdande CA-roten
Compliance-team	Måste visa att certifikatutfärdande via NDES loggas, övervakas och granskas; NDES är en kritisk kontrollpunkt för certifikatbaserad autentiseringsbevis	Bekräfta att CA-utfärdandeloggar samlar in alla SCEP-registrerade certifikat; integrera NDES IIS-loggar med SIEM; inkludera NDES-utfärdade certifikat i kvartalsvis certifikatinventering och granskningsomfattning
CISO: er	Äg riskregisterposten för NDES som en värdefull attackyta, eftersom NDES-kompromettering möjliggör obehörig certifikatutfärdande som kan användas för autentisering och lateral förflyttning	Kräv att NDES bedöms i alla PKI-säkerhetsrevisioner; finansiera CLM-verktyg för enhetlig insyn i NDES-utfärdade certifikat; inkludera NDES-tillgänglighet i PKI-motståndskraftsrapportering

Vad är SCEP?

SCEP, eller Simple Certificate Enrollment Protocol , är ett protokoll som ursprungligen utvecklades av Cisco för att automatisera certifikatregistrering för nätverksenheter som inte enkelt kan ansluta till Active Directory. Till skillnad från traditionella AD-baserade registreringsmetoder tillåter SCEP enheter att begära certifikat med HTTP/ HTTPS , autentisera med en delad hemlighet eller ett utmanande lösenord och automatiskt hämta signerade certifikat.

SCEP utformades för enheter som routrar och switchar, VPN-gateways, nätverksapparater, IoT-enheter och mobila enheter. Med tiden har det utvecklats till de facto-standarden för certifikatregistrering i enhetshanteringsplattformar, inklusive Microsoft Intune och många MDM-lösningar.

Vad är NDES?

NDES (Network Device Enrollment Service) är Microsofts implementering av SCEP. Den fungerar som en brygga mellan enheter och Microsofts certifieringsutfärdare, vilket gör att enheter som inte kan autentisera via Active Directory fortfarande kan hämta certifikat på ett säkert sätt. Utan NDES kan SCEP inte användas med Microsoft ADCS.

Enkelt uttryckt fungerar det så här:

1. Enheter kommunicerar med NDES med hjälp av SCEP
2. NDES validerar begäran
3. NDES skickar begäran till Microsoft CA
4. CA utfärdar certifikatet
5. NDES levererar den tillbaka till enheten

Förutsättningar innan NDES distribueras

Innan du distribuerar NDES, bekräfta att vart och ett av följande är på plats. En saknad förutsättning är den vanligaste orsaken till NDES-installationsfel och registreringsfel efter distribution.

Förutsättning	Krav	Valideringskontroll	Vanligt fel om det saknas	Ägare
ADCS-miljö	Minst en utfärdande CA som körs på Windows Server 2012 R2 eller senare; rot-CA tillgänglig för kedjevalidering	Körning certutil -ping mot CA från NDES-servern för att bekräfta RPC-anslutning	NDES-installationen misslyckas med felet "Certifieringsutfärdaren kan inte nås" under konfigurationen	PKI-administratör
Dedikerad NDES-server	Windows Server 2016 eller senare; NDES får INTE installeras på själva CA-servern; IIS måste installeras före NDES-rollen	Bekräfta att servern är domänansluten och att IIS standardwebbplats körs innan NDES-rollen installeras	Om NDES installeras på CA kommer det att komma i konflikt med CA RPC-lyssnare; installationen kan lyckas men registreringen misslyckas vid körning	PKI-administratör
NDES-tjänstkonto	Dedikerat domänkonto (inte en domänadministratör); måste finnas i den lokala IIS_IUSRS-gruppen; måste ha registreringsbehörighet för SCEP-certifikatmallen; måste ha behörighet att "Logga in som en tjänst"	Bekräfta att kontot INTE är medlem i Domänadministratörer; bekräfta Registrera ACE på mallens fliken Säkerhet	HTTP 500 på NDES-URL eller hämtning av lösenord för utmaning misslyckades om kontot saknar CA-registreringsrättigheter	PKI-administratör / Säkerhetsarkitekt
Certifikatmall	Mall konfigurerad för SCEP: Nyckelanvändning = Digital signatur; EKU = Klientautentisering (och andra efter behov); privat nyckel kan inte exporteras; Ange ämnesnamn i begäran	Öppna mallen i certtmpl.msc; bekräfta inställningar för nyckelanvändning, EKU och privat nyckel; bekräfta att mallen är publicerad på den utfärdande CA:n	Certifikatbegäran avvisas av CA om mallens EKU inte matchar avsedd användning; NDES returnerar HTTP 400 till den begärande enheten	PKI-administratör
SSL-certifikat för NDES HTTPS-slutpunkt	Giltigt SSL/TLS-certifikat kopplat till NDES IIS-webbplatsen; utfärdande certifikatutfärdare måste vara betrodd av alla enheter som använder NDES; TLS 1.2 eller senare tillämpas	Bläddra till NDES HTTPS-URL:en från en testenhet och bekräfta att det inte finns någon certifikatvarning; kontrollera IIS-bindningar i inetmgr	Enheter avvisar NDES-anslutningen om SSL-certifikatet är självsignerat eller utfärdat av en otillförlitlig certifikatutfärdare; Intune rapporterar registreringsfel	PKI-administratör / plattformsteam
Nätverksåtkomst	Enheter måste nå NDES HTTPS-slutpunkt på TCP 443; NDES-servern måste nå CA på TCP 135 och dynamiska RPC-portar; omvänd proxy eller applikationsgateway rekommenderas för internetbaserade distributioner.	Körning Test-NetConnection -ComputerName ndes.contoso.com -Port 443 från en testenhet; bekräfta att brandväggsregler tillåter CA RPC från NDES-servern	Registreringstidsgränser eller TCP-återställningsfel på enheter om brandväggen blockerar NDES HTTPS; tysta CA-inlämningsfel om NDES inte kan nå CA på RPC	Säkerhetsarkitekt / Nätverksteam

Varför NDES fortfarande spelar roll i modern PKI

Vissa administratörer antar att SCEP är föråldrat eftersom det skapades för årtionden sedan. SCEP-användningen har faktiskt ökat dramatiskt på grund av moderna trender inom enhetshantering. Följande tre användningsfall illustrerar var NDES fortfarande är viktigt idag.

1. Registrering av Microsoft Intune-enhetscertifikat

Organisationer som distribuerar Intune förlitar sig ofta på NDES för att utfärda enhetsautentiseringscertifikat, Wi-Fi-certifikat, VPN-certifikat och e-postautentiseringscertifikat. Utan NDES kan Intune inte utfärda certifikat från lokala ADCS. Detta gör NDES till ett beroende för alla hybriddistributioner av Intune som förlitar sig på en intern CA snarare än en molnbaserad CA.

2. Klientautentiseringscertifikat

NDES används ofta för att utfärda klientautentiseringscertifikat för Windows Always-On VPN, VPN-klienter från tredje part och hybridarkitekturer för fjärråtkomst. Detta möjliggör lösenordsfri VPN-autentisering kopplad till enhetsidentitet , vilket är en grundläggande kontroll i Zero Trust-nätverksåtkomstmodeller.

3. Registrering av IoT och nätverksenheter

NDES tillåter utfärdande av certifikat till skrivare, kameror, tillverkningssystem och nätverksenheter. Dessa enheter kan ofta inte ansluta till AD, vilket gör SCEP till det enda skalbara alternativet. I OT- och industriella miljöer där antalet enheter uppgår till tusentals, tillhandahåller PKIaaS-baserade NDES eller PKI-as-a-Service den skalbara utfärdandeinfrastruktur som dessa miljöer kräver.

Hur NDES fungerar: Arkitekturöversikt

En typisk NDES-distribution innefattar fyra komponenter: den begärande enheten (MDM-hanterad eller nätverksenhet), NDES-servern, Microsofts certifieringsutfärdare (CA) och certifikatmallen som konfigurerats för SCEP.

Steg 1: Registrering av enhetsbegäranden

Enheten kontaktar NDES HTTPS-slutpunkten med hjälp av SCEP. För Intune-hanterade enheter utlöses detta automatiskt av en Intune SCEP-profil. Enheten genererar ett nyckelpar och konstruerar en PKCS#10-certifikatsigneringsbegäran (CSR).

Steg 2: NDES utfärdar ett lösenord för utmaningen

NDES genererar ett engångslösenord (OTP) som används för att validera begäran. I Intune-integrerade distributioner förauktoriserar Intune begäran och tillhandahåller utmaningen via NDES-anslutningen, så ingen manuell OTP-hämtning krävs.

Steg 3: Enheten skickar in certifikatbegäran

Enheten skickar sin certifikatsigneringsbegäran tillsammans med lösenordet för utmaningen till NDES med hjälp av en HTTP POST till SCEP-slutpunkten. NDES validerar utmaningen innan begäran vidarebefordras till certifikatutfärdaren.

Steg 4: NDES skickas till CA

NDES vidarebefordrar begäran till Microsoft CA med hjälp av NDES-tjänstkontots autentiseringsuppgifter och den angivna certifikatmallen. CA utvärderar begäran mot mallens policy, nyckelanvändning, EKU och inställningar för ämnesnamn innan certifikatet utfärdas eller avvisas.

Steg 5: Certifikatet utfärdas

CA signerar certifikatet och returnerar det till NDES. CA-utfärdandehändelsen loggas i CA-databasen och händelseloggen. Det är här SIEM-integrationen ska registrera utfärdandehändelsen för revisionsloggsändamål.

Steg 6: Enheten hämtar certifikat

Enheten avsöker NDES-slutpunkten och hämtar det signerade certifikatet. Enheten installerar det i lämpligt certifikatarkiv (maskinarkiv för enhetsautentisering, användararkiv för användarcertifikat). CLM-plattformen bör registrera detta certifikat i inventeringen vid denna tidpunkt för spårning och förnyelsehantering.

Vanliga NDES-felkonfigurationer som finns i säkerhetsbedömningar

I PKI-säkerhetsbedömningar förekommer flera återkommande NDES-felkonfigurationer konsekvent. Var och en representerar en verklig attackvektor.

1. NDES exponerad direkt för internet

NDES-slutpunkter körs ofta på IIS och kan publiceras externt utan skydd. Detta gör det möjligt för angripare att försöka registrera certifikat, räkna upp mallar och utnyttja IIS-sårbarheter. NDES bör alltid skyddas av programgatewayer och rollbaserade åtkomstregler. Publicera aldrig den råa NDES-URL:en direkt till internet; dirigera alltid via en omvänd proxy eller Azure Application Proxy som kan framtvinga autentisering innan begäranden når NDES.

2. Överprivilegierade servicekonton

NDES använder ett tjänstkonto för att begära certifikat från CA. Om detta konto har för många behörigheter kan angripare som komprometterar det utfärda certifikat oberoende. Denna risk är särskilt allvarlig eftersom certifikat kan användas för autentisering och lateral förflyttning. NDES-tjänstkontot ska endast ha registreringsbehörighet på den angivna SCEP-mallen, lokalt IIS_IUSRS-medlemskap och rättigheterna Logga in som en tjänst. Det ska aldrig vara medlem i Domänadministratörer eller CA-administratörer.

3. Svag mallkonfiguration

Mallar som används för SCEP är ibland konfigurerade för att tillåta exporterbara privata nycklar, tillåta alltför breda användningsrättigheter (t.ex. både klient- och serverautentisering i samma mall) och utfärda certifikat utan kontroller för godkännande av chefer. Dessa felkonfigurationer kan leda till identitetskompromiss och missbruk av certifikat. Inaktivera alltid export av privata nycklar på SCEP-mallar. Ange den lägsta EKU som krävs för användningsfallet. Överväg att aktivera godkännande av CA-chef för mallar med hög behörighet även när SCEP används.

4. Brist på övervakning och loggning

Många organisationer distribuerar NDES men övervakar det aldrig. Utan korrekt övervakning och loggning går oärlig certifikatutfärdande obemärkt förbi, missbruk av registreringar kan inte upptäckas och incidenthantering blir svår. Integrera CA-händelseloggar (händelse-ID 4886 för certifikatförfrågningar, händelse-ID 4887 för certifikatutfärdande) med din SIEM. Ställ in aviseringar för onormala registreringsvolymtoppar från en enda käll-IP eller enhet. Använd CBOM Secure för att upprätthålla kontinuerlig kryptografisk inventering av alla NDES-utfärdade certifikat.

Bästa säkerhetspraxis för NDES-distributioner

För att säkra NDES i moderna miljöer bör organisationer följa dessa bästa praxis. För mer information, se den medföljande guiden: Bästa praxis för NDES-säkerhet.

1. Isolera NDES-servrar

NDES bör aldrig installeras direkt på CA:n. Distribuera det i ett dedikerat DMZ-segment, bakom en omvänd proxy eller applikationsgateway, med begränsad nätverksåtkomst till CA:n (endast CA RPC-portar, blockerad från alla andra interna segment). Detta begränsar sprängradien om NDES-servern komprometteras.

2. Begränsa mallbehörigheter

SCEP-mallar bör endast tillåta obligatoriska EKU:er, begränsa format för ämnesnamn till Supply i begäran (validerad via NDES-utmaning), inaktivera export av privata nycklar och ställa in registreringsbehörigheter endast för NDES-tjänstkontot snarare än domändatorer i stort.

3. Övervaka certifikatutfärdande

Logga alla SCEP-förfrågningar via IIS-loggar och CA-händelseloggar. Övervaka mallanvändning efter mallnamn och begärande konto. Varna för onormala registreringsvolymer (t.ex. mer än 50 certifikatförfrågningar per timme från en enda källa). Detta är särskilt viktigt för mallar som beviljar klientautentiseringscertifikat, eftersom dessa kan användas för lateral förflyttning om de erhålls av en angripare.

4. Härda IIS-konfigurationen

Eftersom NDES körs på IIS, inaktivera oanvända IIS-moduler, tillämpa TLS 1.2 eller högre på NDES HTTPS-bindning, tillämpa HTTPS-säkerhetsrubriker (HSTS, X-Content-Type-Options, X-Frame-Options) och uppdatera regelbundet servern. NDES IIS-platsen bör vara den enda platsen på servern; samlokalisera inte andra applikationer.

Där SCEP och NDES börjar visa begränsningar

Trots deras utbredda användning var SCEP och NDES ursprungligen inte utformade för dagens molnbaserade miljöer. Flera utmaningar uppstår ofta i moderna implementeringar.

Begränsad säkerhetskontext

SCEP utformades för enkelhet, vilket innebär att det ger begränsade identitetsvalideringsmöjligheter. Lösenordsutmaningsmekanismen är en delad hemlighet, inte ett kryptografiskt bundet identitetsbevis. Ytterligare kontroller måste ofta läggas ovanpå (till exempel Intunes förauktorisering via NDES-anslutningen) för att säkerställa stark enhetsautentisering innan certifikat utfärdas.

Operationell komplexitet

NDES-distributioner kräver dedikerade servrar, IIS-härdning, planering av nätverksexponering, hantering av mallkonfiguration och livscykelhantering för tjänstekonton. I hybrid- eller multimolnmiljöer med flera NDES-instanser introducerar detta betydande driftskostnader utan enhetliga CLM-verktyg som ger insyn i alla instanser.

Skalningsutmaningar

Medan SCEP fungerar bra för slutpunktsenheter är det mindre lämpat för dynamiska arbetsbelastningar som containrar, mikrotjänster eller tillfälliga molninstanser. Dessa moderna arbetsbelastningar kräver snabbare certifikatutfärdandecykler, starkare identitetsverifieringsmekanismer och kortlivade certifikat. ACME hanterar dessa scenarier mer effektivt.

Det moderna ramverket för certifikatautomation: ACME

ACME (Automated Certificate Management Environment) utvecklades för att möjliggöra helt automatiserad hantering av certifikatlivscykeln med minimal mänsklig inblandning. Till skillnad från SCEP byggdes ACME för moderna miljöer och stöder automatiserad utfärdande och förnyelse av certifikat, API-drivna arbetsflöden, identitetsverifieringsmekanismer och kortlivade certifikat i linje med Zero Trust-principerna.

ACME är särskilt värdefullt för DevOps-pipelines, Kubernetes-kluster, molnbaserade tjänster och tjänst-till-tjänst-autentisering. Företag använder det i allt högre grad internt för arbetsbelastningsidentiteter tillsammans med SCEP/NDES för enhetscertifikat.

Jämförelse av SCEP, NDES och ACME i Enterprise PKI

Varje teknik tjänar ett annat syfte. Organisationer använder dem ofta tillsammans snarare än att välja bara en.

Dimensionera	SCEP / NDES	ACME	Automatisk registrering för AD
Primärt användningsfall	Enhetscertifikat för Intune-hanterade slutpunkter, VPN-klienter, IoT, nätverksapparater	Server- och arbetsbelastningscertifikat för DevOps-pipelines, Kubernetes och molnbaserade tjänster	Användar- och datorcertifikat för domänanslutna Windows-system
Enhetskrav	Kräver inte Active Directory-medlemskap; använder problemlösenord för autentisering	Kräver inte AD; använder domänvalidering eller API-tokenautentisering	Kräver medlemskap i Active Directory och gruppolicy
Certifikatets livslängd	Stöder enhetscertifikat med längre livslängd (typiskt: 1 år); förnyelse via ny SCEP-begäran	Utformad för certifikat med kort livslängd (dagar till 90 dagar); automatisk förnyelse inbyggd i protokollet	Stöder alla giltighetsperioder som konfigurerats i mallen; förnyelse via automatisk registrering av GPO
Infrastruktur som krävs	NDES-server (dedikerad Windows Server + IIS), NDES-tjänstkonto, CA RPC-åtkomst	ACME-kompatibel CA-slutpunkt; ingen dedikerad server krävs utöver själva CA:n	Domänkontrollant, grupprincip, domänansluten certifikatutfärdare
Moln-/hybridstöd	Fungerar med Intune via NDES-anslutning; kräver lokal NDES-server för lokal ADCS	Inbyggt i molnbaserade certifikatutfärdare; fungerar utan lokal infrastruktur	Kräver lokal AD; inte lämplig för molnbaserade enheter eller BYOD-enheter
PQC-beredskap	Begränsad; beror på CA och mallalgoritmkonfiguration; ingen inbyggd algoritmförhandling	Stark; algoritmförhandling inbyggd i protokollet; redo för NIST FIPS 203/204/205-migrering	Beror på CA-mallkonfiguration; kräver malluppdatering för PQC-algoritmer
Bäst för	Intune-enhetscertifikat, VPN-certifikat, Wi-Fi-certifikat, IoT-enhetsidentitet	Webbserver-TLS, containeridentitet, CI/CD-pipelinecertifikat, kortlivade tjänstcertifikat	Domänanslutna Windows-användar- och datorcertifikat

Verkligt exempel: Hybrid företagsdistribution

Tänk dig ett företag som inför Zero Trust och samtidigt migrerar till molnet. De kan distribuera NDES integrerat med Intune för att hantera enhetscertifikat, ACME-baserad utfärdande för containerarbetsbelastningar och automatisk ADCS-registrering för interna servrar. Denna hybridmodell gör det möjligt för dem att upprätthålla kompatibilitet med äldre system samtidigt som de moderniserar certifikatlivscykelhanteringen. Det minskar också beroendet av lösenord och stärker identitetsbaserade åtkomstkontroller i hela miljön.

Hur man väljer rätt registreringsmetod

Om ditt fokus ligger på slutanvändarenheter eller nätverksapparater som inte kan ansluta till Active Directory, är SCEP med NDES fortfarande praktiskt och har ett brett stöd. Om ditt fokus ligger på moderna arbetsbelastningar eller automatiseringstunga miljöer erbjuder ACME starkare integration och skalbarhet. Om du hanterar domänanslutna Windows-system med grupprincip är automatisk AD-registrering den mest effektiva vägen.

De flesta företag kommer att behöva alla tre under sin övergång till molnbaserade säkerhetsmodeller. En enhetlig CLM-plattform som CertSecure Manager ger en enda överblick över alla tre utfärdandevägar, vilket säkerställer att inget certifikat slipper undan lagret oavsett hur det utfärdades.

Framtiden för registrering av företagscertifikat

Certifikatbaserad autentisering blir snabbt standardmekanismen för att säkra företagsmiljöer. I takt med att organisationer går mot lösenordslös autentisering, enhetsidentitetskontroll, Zero Trust-åtkomstmodeller och molnbaserad arkitektur, blir certifikatautomation en central säkerhetsfunktion snarare än en nischad PKI-funktion.

SCEP och NDES kommer sannolikt att fortsätta användas för enhetsregistrering, medan ACME-användningen fortsätter att öka för arbetsbelastningsidentiteter och infrastrukturautomation. NIST slutförde FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA) i augusti 2024. Organisationer som inte har påbörjat PQC-beredskapsplanering kommer att behöva uppdatera CA-algoritmprofiler och certifikatmallar för att stödja post-kvantumalgoritmer. Börja med PQC-beredskapsbedömningen och PQC Center of Excellence för NIST-anpassad migreringsplanering.

Hur krypteringskonsulting kan hjälpa

Encryption Consulting har omfattande erfarenhet av att leverera kompletta PKI-lösningar för företag och myndigheter. Vi erbjuder både professionella tjänster och vår automatiseringsplattform ( CertSecure Manager ) för att säkerställa att er PKI är säker, robust och framtidsklar.

PKI-tjänster

Heltäckande rådgivnings-, design- och implementeringstjänster som hjälper organisationer att bygga, modernisera och styra säkra miljöer med offentlig nyckelinfrastruktur.

Projekt planering

Vi utvärderar er kryptografiska miljö, granskar PKI-konfigurationer, beroenden och krav, och sammanställer resultaten i en strukturerad, kundgodkänd projektplan.

CP/CPS-utveckling

Vi utvecklar certifikatpolicyer (CP) och certifieringspraxis (CPS) i linje med RFC 3647. Dessa dokument är anpassade till din organisations regulatoriska, säkerhetsmässiga och operativa krav.

PKI-design och implementering

Vi designar och driftsätter robusta PKI-infrastrukturer, inklusive offline-root-CA:er, utfärdande CA:er, NDES-servrar och HSM-integration, beroende på kundens behov. Leveranserna inkluderar PKI-designdokument, byggguider, ceremoniskript och systemkonfigurationer. När driftsättningen är klar genomför vi grundliga tester, validering, finjusteringar och kunskapsöverföringssessioner för att stärka ditt team.

Företagets kontinuitet och katastrofåterställning

Efter driftsättningen utvecklar och implementerar vi strategier för affärskontinuitet och katastrofåterställning, genomför redundantester och dokumenterar operativa arbetsflöden för hela PKI- och HSM-infrastrukturen, med stöd av en omfattande PKI-driftsguide.

Löpande support och underhåll (valfritt)

Efter implementeringen erbjuder vi ett prenumerationsbaserat årligt supportpaket som ger omfattande täckning för PKI-, CLM- och HSM-komponenter. Detta inkluderar incidenthantering, felsökning, systemoptimering, hantering av certifikatlivscykeln, CP/CPS-uppdateringar, nyckelarkivering, uppgraderingar av HSM-firmware, granskningsloggning och patchhantering.

Denna metod säkerställer att din PKI-infrastruktur inte bara är säker och kompatibel, utan också skalbar, robust och helt i linje med dina långsiktiga operativa och regulatoriska mål.

CertSecure-hanterare

CertSecure Manager från Encryption Consulting är en lösning för hantering av certifikatlivscykeln som förenklar och automatiserar hela livscykeln, så att du kan fokusera på säkerhet snarare än förnyelser.

• Automatisering för kortlivade certifikat: Med ACME- och 90-dagars/47-dagars TLS-certifikat som blir standard är manuell förnyelse inte längre ett praktiskt alternativ. CertSecure Manager automatiserar registrering, förnyelse och driftsättning för att säkerställa att certifikat aldrig går ut obemärkt.
• Sömlös DevOps- och molnintegration: Certifikat kan tillhandahållas direkt till webbservrar och molninstanser, och de integreras med moderna loggverktyg som Datadog, Splunk, ITSM-verktyg som ServiceNow och DevOps-verktyg som Terraform och Ansible.
• Stöd för flera CA: Många organisationer använder flera CA:er (interna Microsoft CA, publika CA:er som DigiCert och GlobalSign, etc.). CertSecure Manager integreras mellan dessa källor och ger en enda ruta för utfärdande och livscykelhantering över SCEP/NDES- och ACME-registreringsvägar.
• Enhetliga utgivnings- och förnyelsepolicyer: CertSecure Manager tillämpar konsekvent din organisations nyckelstorlekar, algoritmer och förnyelseregler för alla certifikat, vilket säkerställer att varje certifikat uppfyller dina säkerhetsstandarder varje gång.
• Proaktiv övervakning och förnyelsetestning: Kontinuerlig övervakning, i kombination med simulerade förnyelse- och utgångstester, säkerställer att du identifierar risker innan certifikat påverkar produktionssystemen.
• Centraliserad synlighet och efterlevnad: En konsoliderad instrumentpanel visar alla certifikat, nyckellängder, starka och svaga algoritmer och deras utgångsdatum. Revisionsspår och policytillämpning förenklar efterlevnaden PCI DSS, HIPAAoch andra ramverk.

Om du undrar var du ska börja med att säkra din PKI, finns Encryption Consulting här för att stödja dig med sina PKI-supporttjänster . Du kan räkna med oss ​​som din betrodda partner, och vi kommer att vägleda dig genom varje steg med tydlighet, förtroende och praktisk expertis.

Slutsats

Enterprise PKI utvecklas från ett backend-säkerhetsverktyg till en central identitetsinfrastruktur. Att förstå hur SCEP, NDES och ACME interagerar gör det möjligt för organisationer att bygga skalbara pipelines för certifikathantering som stöder både äldre miljöer och moderna molnarbetsbelastningar. Genom att kombinera traditionella PKI-grunder med moderna automatiseringsramverk kan företag gå mot starkare identitetsdriven säkerhet utan att offra driftseffektiviteten.

NDES är fortfarande avgörande för hybrid Intune-distributioner och registrering av certifikat för icke-domänenheter, men det måste distribueras och säkras med samma noggrannhet som tillämpas på själva CA:n. Behandla varje felkonfigurerad NDES-server som en potentiell bakdörr för certifikatutfärdande. Investera i CLM-verktyg för att bibehålla full insyn i NDES-utfärdade certifikat och börja planera PQC-beredskap nu så att algoritmövergångar inte kräver akuta CA-ombyggnader när de regulatoriska deadlines anländer.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från NDES och SCEP Explained: The Backbone of Automated Certificate Enrollment?

SCEP är fortfarande det faktiska protokollet för automatiserad registrering av enhetscertifikat i Microsoft PKI-miljöer, och NDES är den obligatoriska bryggan mellan SCEP-talande enheter och ADCS. Utan NDES kan Intune, MDM-plattformar och enheter utanför domänen inte hämta certifikat från en lokal certifikatutfärdare. Felkonfigurerade NDES-servrar är en av de vanligast utnyttjade PKI-svagheterna och bör behandlas med samma säkerhetsnoggrannhet som själva certifikatutfärdaren.

Varför är NDES och SCEP viktiga för PKI-team på stora företag?

Företags-PKI-team ansvarar för den certifikatinfrastruktur som Intune-, MDM-, VPN-, Wi-Fi- och Zero Trust-åtkomstsystem är beroende av. NDES är hur dessa system hämtar certifikat från ADCS för enheter som inte tillhör domänen. Enligt DigiCerts Trust Pulse Survey (2 juli 2025) upplevde nästan hälften av företagen certifikatrelaterade driftstopp under det senaste året. En felkonfigurerad eller otillgänglig NDES-server kan bryta enhetsautentiseringen i en hel organisation samtidigt.

Vilka risker ökar om NDES och SCEP inte är ordentligt säkrade?

Riskerna inkluderar: en internet-exponerad NDES-slutpunkt gör det möjligt för angripare att räkna upp certifikatmallar och försöka obehörig registrering; ett överprivilegierat servicekonto gör det möjligt för angripare att imitera det och utfärda certifikat oberoende av varandra; svag mallkonfiguration med exporterbara privata nycklar skapar identitetskomprometteringsvektorer; och avsaknad av övervakning innebär att oärlig certifikatutfärdande går oupptäckt förrän en incident inträffar.

Vilka team bör äga NDES- och SCEP-distribution och säkerhet?

PKI-administratörer äger NDES-serverdistribution, konfiguration av certifikatmallar och CA-policy. Säkerhetsarkitekter äger nätverksisoleringsdesignen och IIS-härdningsstandarder. Plattforms- och slutpunktsteam äger MDM/Intune-integrationen och enhetsregistreringsprofilerna. Efterlevnadsteam äger kraven för granskningsloggar och övervakningsbevis. CISO:er äger riskregisterposten för NDES som en värdefull attackyta med tanke på dess roll i certifikatutfärdande för autentisering.

Hur kopplas NDES och SCEP till hantering av certifikatlivscykeln?

NDES och SCEP hanterar de initiala certifikatregistrerings- och förnyelseförfrågningarna från enheter. Certifikatlivscykelhantering (CLM) tillhandahåller det bredare operativa lagret som spårar, övervakar och hanterar alla certifikat i hela miljön. CertSecure Manager integreras med SCEP/NDES-registreringsflöden och ger enhetlig insyn i ADCS-utfärdade certifikat, offentliga CA-certifikat och molnutfärdade certifikat i en enda instrumentpanel med automatiserade arbetsflöden för utgångsdatum och förnyelse.

Hur bör organisationer mäta framgång efter att ha infört NDES?

Viktiga mätvärden inkluderar: andel målenheter som registrerats via SCEP/NDES (mål: 100 % av MDM-hanterade enheter); antal misslyckade SCEP-registreringsförsök per vecka (mål: trend mot noll efter initial stabilisering); autentiseringsfel relaterade till certifikatutgång orsakade av NDES-utfärdade certifikat per kvartal (mål: noll); tid för att upptäcka ett falskt eller obehörigt certifikat utfärdat via NDES (mål: samma dag via SIEM-avisering); och NDES-servertillgänglighet (mål: minst 99.9 %).

Vad bör granskas eller övervakas regelbundet i en NDES-implementering?

Övervaka kontinuerligt: ​​volymer och felfrekvenser för SCEP-registreringsförfrågningar; certifikat utfärdade via NDES i CA-databasen; NDES IIS-applikationspoolens hälsa; och nätverksåtkomst till NDES-slutpunkten från oväntade käll-IP-adresser. Granska kvartalsvis: NDES-tjänstkontobehörigheter mot krav på lägsta behörighet; konfiguration av certifikatmall för SCEP; IIS-konfiguration för TLS-versionstillämpning; och NDES-serverns OS-patchnivå.

Hur påverkar NDES moln-, hybrid- eller multi-CA-miljöer?

I hybridmiljöer där Intune hanterar både molnbaserade och lokala enheter är NDES den nödvändiga bryggan för att utfärda certifikat från lokala ADCS till molnhanterade enheter. I miljöer med flera CA:er kan organisationer köra flera NDES-instanser. Utan CLM-verktyg som ger enhetlig synlighet skapar certifikat som utfärdas av olika NDES-instanser över olika CA:er blinda fläckar i inventeringen. CBOM Secure automatiserar kryptografisk identifiering i dessa hybridmiljöer för att upprätthålla en komplett och granskningsbar certifikatinventering.

Vilka förutsättningar krävs innan man distribuerar NDES?

Förutsättningarna inkluderar: en aktiv ADCS-miljö med minst en utfärdande CA; Windows Server 2016 eller senare för NDES-rollen; ett dedikerat tjänstkonto med CA-registreringsrättigheter och IIS-åtkomst (inte en domänadministratör); en certifikatmall konfigurerad för SCEP-registrering med korrekt nyckelanvändning (digitalSignature), EKU och inga exporterbara privata nycklar; IIS installerat på NDES-servern; och ett giltigt SSL-certifikat för NDES HTTPS-slutpunkten. NDES får inte installeras på själva CA-servern.

Vilka vanliga fel bör administratörer vara uppmärksamma på när de distribuerar NDES?

Vanliga fel inkluderar: HTTP 403 på NDES-URL:en orsakad av IIS-behörigheter eller problem med programpoolens identitet; misslyckanden med att hämta lösenord för utmaningar orsakade av att NDES-tjänstkontot saknar registreringsbehörighet för certifikatutfärdare; avslag på certifikatförfrågningar orsakade av felaktig mallkonfiguration eller saknad EKU; NDES-programpoolkrasch orsakad av minnes- eller IIS-modulproblem; och enheter som inte kan lita på NDES SSL-certifikatet eftersom den utfärdande certifikatutfärdaren inte finns i enhetens förtroendearkiv.