NDES en SCEP uitgelegd: De ruggengraat van geautomatiseerde certificaatinschrijving

Naarmate organisaties sneller overstappen op Zero Trust, apparaatauthenticatie en cloudgebaseerde infrastructuur, is traditionele handmatige certificaatregistratie niet langer schaalbaar. Of het nu gaat om het onboarden van duizenden laptops via Intune, het uitgeven van certificaten voor VPN-toegang of het inschakelen van wifi-authenticatie in wereldwijde vestigingen, geautomatiseerde certificaatregistratie is essentieel.

Hier spelen SCEP (Simple Certificate Enrollment Protocol) en NDES (Network Device Enrollment Service) een cruciale rol in Microsoft PKI-ecosystemen. Ondanks hun belang implementeren veel beheerders ze zonder volledig te begrijpen hoe ze werken, waarin ze verschillen of hoe ze correct beveiligd moeten worden. Verkeerd geconfigureerde NDES-servers blijven een van de meest voorkomende PKI- zwakheden die tijdens beveiligingsaudits worden ontdekt.

Kort antwoord: Wat zijn NDES en SCEP?

SCEP (Simple Certificate Enrollment Protocol) is het protocol waarmee apparaten certificaten kunnen aanvragen via HTTP/HTTPS zonder zich aan te melden bij Active Directory. NDES (Network Device Enrollment Service) is Microsofts implementatie van SCEP en fungeert als de brug tussen SCEP-compatibele apparaten en ADCS. Zonder NDES kunnen Intune- en MDM-platformen geen certificaten uitgeven van een lokale certificeringsinstantie (CA).

Key Takeaways

• NDES is de vereiste brug tussen SCEP-compatibele apparaten (Intune-beheerde endpoints, IoT-apparaten, VPN-gateways, netwerkapparaten) en Microsoft ADCS. Zonder NDES kunnen deze apparaten geen certificaten verkrijgen van een lokale CA.
• Verkeerd geconfigureerde NDES-servers behoren tot de meest voorkomende kwetsbaarheden voor PKI-aanvallen. Een via internet toegankelijk NDES-eindpunt, een serviceaccount met te hoge privileges of een zwakke certificaatsjabloon kunnen elk afzonderlijk leiden tot ongeautoriseerde certificaatuitgifte.
• Volgens de Trust Pulse Survey van DigiCert (2 juli 2025) heeft bijna de helft van alle bedrijven het afgelopen jaar te maken gehad met uitval als gevolg van certificaatproblemen. Een verkeerd geconfigureerde of niet-beschikbare NDES-server zorgt ervoor dat de apparaatauthenticatie in de hele organisatie tegelijkertijd niet meer werkt.
• Het voorstel SC-081v3 (april 2025) van het CA/Browser Forum verkort de maximale geldigheidsduur van openbare TLS-certificaten tot 47 dagen tegen maart 2029. Dit maakt geautomatiseerde SCEP/NDES-registratie en CLM-tools essentieel; handmatige verlenging kan deze frequentie op de schaal van apparaten niet aan.
• SCEP en NDES worden niet vervangen door ACME; ze dienen verschillende gebruiksscenario's. SCEP/NDES beheert apparaatcertificaten voor Intune, VPN en netwerkapparatuur. ACME beheert server- en workloadcertificaten voor DevOps-pipelines, Kubernetes en cloud-native services. De meeste bedrijven hebben beide nodig.

Wie zou zich druk moeten maken over NDES en SCEP?

De implementatie en beveiliging van NDES is een verantwoordelijkheid die meerdere afdelingen delen. Iedere functie hieronder heeft er direct belang bij dat dit goed verloopt.

Rol	Waarom het uitmaakt	Actie-item
PKI-beheerders	Implementatie van een eigen NDES-server, configuratie van certificaatsjablonen voor SCEP, installatie van een CA-inschrijvingsagent en handhaving van CA-beleid voor door NDES uitgegeven certificaten.	Implementeer NDES op een dedicated server (niet de CA); configureer sjablonen met het juiste sleutelgebruik, EKU en zonder exporteerbare privésleutels; integreer CA-uitgiftelogboeken met SIEM.
Beveiligingsarchitecten	Verantwoordelijk zijn voor het ontwerp van de netwerkisolatie, de IIS-beveiligingsnormen en het privilege-model voor NDES-serviceaccounts, die bepalend zijn voor het aanvalsoppervlak van de NDES-implementatie.	Plaats NDES in een DMZ achter een reverse proxy of applicatiegateway; handhaaf het principe van minimale bevoegdheden voor het NDES-serviceaccount; definieer ACL's voor certificaatsjablonen die SCEP-inschrijving beperken tot geautoriseerde apparaten.
Platform-/eindpuntteams	Beheer de Intune-, MDM- en apparaatbeheerintegratie die afhankelijk is van NDES voor de levering van certificaten aan beheerde apparaten.	Configureer Intune SCEP-profielen die verwijzen naar het NDES HTTPS-eindpunt; test de certificaatlevering aan verschillende apparaattypen (Windows, iOS, Android, macOS); bevestig dat de vertrouwensarchief van het apparaat de uitgevende CA-root bevat;
Compliance	Er moet worden aangetoond dat de uitgifte van certificaten via NDES wordt geregistreerd, gecontroleerd en controleerbaar is; NDES is een cruciaal controlepunt voor bewijs van certificaatgebaseerde authenticatie.	Bevestig dat de CA-uitgiftelogboeken alle SCEP-geregistreerde certificaten vastleggen; integreer de NDES IIS-logboeken met SIEM; neem door NDES uitgegeven certificaten op in de driemaandelijkse certificaatinventarisatie en het auditbereik.
CISO's	Beschouw de vermelding van NDES in het risicoregister als een waardevol aanvalsoppervlak, omdat een inbreuk op NDES de ongeautoriseerde uitgifte van certificaten mogelijk maakt die gebruikt kunnen worden voor authenticatie en laterale verplaatsing.	Eis dat NDES wordt meegenomen in elke PKI-beveiligingsaudit; financier CLM-tools voor uniforme zichtbaarheid van door NDES uitgegeven certificaten; neem de beschikbaarheid van NDES op in rapportages over de veerkracht van de PKI.

Wat is SCEP?

SCEP, ofwel Simple Certificate Enrollment Protocol , is een protocol dat oorspronkelijk door Cisco is ontwikkeld om de certificaatinschrijving te automatiseren voor netwerkapparaten die niet eenvoudig kunnen worden toegevoegd aan Active Directory. In tegenstelling tot traditionele AD-gebaseerde inschrijvingsmethoden, stelt SCEP apparaten in staat om certificaten aan te vragen via HTTP/ HTTPS , te authenticeren met behulp van een gedeeld geheim of een uitdagingswachtwoord, en automatisch ondertekende certificaten op te halen.

SCEP is ontworpen voor apparaten zoals routers en switches, VPN-gateways, netwerkapparatuur, IoT-apparaten en mobiele apparaten. In de loop der tijd is het uitgegroeid tot de de facto standaard voor certificaatinschrijving in platformen voor apparaatbeheer, waaronder Microsoft Intune en veel MDM-oplossingen.

Wat is NDES?

NDES (Network Device Enrollment Service) is Microsofts implementatie van SCEP. Het fungeert als een brug tussen apparaten en de Microsoft Certification Authority, waardoor apparaten die niet via Active Directory kunnen authenticeren toch veilig certificaten kunnen verkrijgen. Zonder NDES kan SCEP niet worden gebruikt met Microsoft ADCS.

Simpel gezegd werkt het als volgt:

1. Apparaten communiceren met NDES via SCEP.
2. NDES valideert het verzoek.
3. NDES dient het verzoek in bij Microsoft CA.
4. De CA geeft het certificaat uit.
5. NDES stuurt het terug naar het apparaat.

Voorwaarden voor het implementeren van NDES

Controleer voordat u NDES implementeert of aan alle onderstaande voorwaarden is voldaan. Een ontbrekende voorwaarde is de meest voorkomende oorzaak van mislukte NDES-installaties en registratiefouten na de implementatie.

Eerste vereiste	eis	Validatiecontrole	Veelvoorkomende fout als deze ontbreekt	Eigenaar
ADCS-omgeving	Ten minste één uitgevende CA die draait op Windows Server 2012 R2 of later; de root-CA moet toegankelijk zijn voor ketenvalidatie.	lopen certutil -ping tegen de CA vanaf de NDES-server om de RPC-connectiviteit te bevestigen.	De NDES-installatie mislukt met de foutmelding "De certificeringsinstantie is niet bereikbaar" tijdens de configuratie.	PKI-beheerder
Speciaal daarvoor bestemde NDES-server	Windows Server 2016 of later; NDES mag NIET op de CA-server zelf worden geïnstalleerd; IIS moet worden geïnstalleerd voordat de NDES-rol wordt geïnstalleerd.	Controleer of de server lid is van het domein en of de standaardwebsite van IIS actief is voordat u de NDES-rol installeert.	Indien geïnstalleerd op een certificeringsinstantie (CA), zal NDES conflicteren met de RPC-listeners van de CA; de installatie kan weliswaar slagen, maar de inschrijving kan tijdens de uitvoering mislukken.	PKI-beheerder
NDES-serviceaccount	Speciaal domeinaccount (geen domeinbeheerder); moet lid zijn van de lokale IIS_IUSRS-groep; moet de machtiging 'Inschrijven' hebben voor de SCEP-certificaatsjabloon; moet het recht 'Aanmelden als service' hebben.	Controleer of het account GEEN lid is van de groep Domeinbeheerders; bevestig dat 'ACE inschrijven' is geselecteerd op het tabblad Beveiliging van de sjabloon.	HTTP 500-fout op de NDES-URL of mislukte poging tot het ophalen van het uitdagingswachtwoord als het account geen CA-registratierechten heeft.	PKI-beheerder / Beveiligingsarchitect
Certificaatsjabloon	Sjabloon geconfigureerd voor SCEP: Sleutelgebruik = Digitale handtekening; EKU = Clientauthenticatie (en andere indien nodig); privésleutel niet exporteerbaar; Geef in het verzoek de onderwerpnaam op.	Open de sjabloon in certtmpl.msc; controleer de instellingen voor sleutelgebruik, EKU en privésleutel; controleer of de sjabloon is gepubliceerd bij de uitgevende CA.	Certificaatverzoek afgewezen door CA als sjabloon EKU niet overeenkomt met het beoogde gebruik; NDES retourneert HTTP 400 naar het aanvragende apparaat.	PKI-beheerder
SSL-certificaat voor NDES HTTPS-eindpunt	Geldig SSL/TLS-certificaat gekoppeld aan de NDES IIS-site; de ​​uitgevende certificeringsinstantie moet vertrouwd worden door alle apparaten die NDES gaan gebruiken; TLS 1.2 of hoger is vereist.	Ga vanaf een testapparaat naar de NDES HTTPS-URL en controleer of er geen certificaatwaarschuwing verschijnt; controleer de IIS-bindingen in inetmgr.	Apparaten weigeren de NDES-verbinding als het SSL-certificaat zelfondertekend is of is uitgegeven door een niet-vertrouwde CA; Intune meldt een mislukte inschrijving.	PKI-beheerder / Platformteam
Netwerktoegang	Apparaten moeten het NDES HTTPS-eindpunt kunnen bereiken via TCP-poort 443; de NDES-server moet de CA kunnen bereiken via TCP-poort 135 en dynamische RPC-poorten; een reverse proxy of applicatiegateway wordt aanbevolen voor implementaties die toegankelijk zijn via internet.	lopen Test-NetConnection -ComputerName ndes.contoso.com -Port 443 vanaf een testapparaat; controleer of de firewallregels CA RPC vanaf de NDES-server toestaan.	Aanmeldingstime-outs of TCP-resetfouten op apparaten als de firewall NDES HTTPS blokkeert; stille CA-inzendingsfouten als NDES de CA niet via RPC kan bereiken;	Beveiligingsarchitect / Netwerkteam

Waarom NDES nog steeds belangrijk is in moderne PKI

Sommige beheerders gaan ervan uit dat SCEP verouderd is omdat het decennia geleden is ontwikkeld. Het gebruik van SCEP is echter juist enorm toegenomen dankzij moderne trends in apparaatbeheer. De volgende drie voorbeelden illustreren waar NDES vandaag de dag nog steeds essentieel is.

1. Microsoft Intune-apparaatcertificaatregistratie

Organisaties die Intune implementeren, vertrouwen vaak op NDES voor het uitgeven van authenticatiecertificaten voor apparaten, wifi-certificaten, VPN-certificaten en e-mailcertificaten. Zonder NDES kan Intune geen certificaten uitgeven vanuit een on-premises ADCS-omgeving. Dit maakt NDES een essentiële vereiste voor elke hybride Intune-implementatie die afhankelijk is van een interne CA in plaats van een cloudgebaseerde CA.

2. Clientauthenticatiecertificaten

NDES wordt vaak gebruikt voor het uitgeven van clientauthenticatiecertificaten voor Windows Always-On VPN, VPN-clients van derden en hybride architecturen voor toegang op afstand. Dit maakt wachtwoordloze VPN-authenticatie mogelijk die is gekoppeld aan de apparaatidentiteit , een fundamentele beveiligingsmaatregel in Zero Trust-netwerktoegangsmodellen.

3. IoT- en netwerkapparaatregistratie

NDES maakt het mogelijk om certificaten uit te geven aan printers, camera's, productiesystemen en netwerkapparaten. Deze apparaten kunnen vaak geen verbinding maken met Active Directory, waardoor SCEP de enige schaalbare optie is. In OT- en industriële omgevingen waar het aantal apparaten in de duizenden loopt, biedt PKIaaS-ondersteunde NDES of PKI-as-a-Service de schaalbare infrastructuur voor certificaatuitgifte die deze omgevingen vereisen.

Hoe NDES werkt: Architectuuroverzicht

Een typische NDES-implementatie bestaat uit vier componenten: het aanvragende apparaat (MDM-beheerd of netwerkapparaat), de NDES-server, de Microsoft- certificeringsinstantie (CA) en de certificaatsjabloon die is geconfigureerd voor SCEP.

Stap 1: Apparaat vraagt ​​registratie aan

Het apparaat neemt via SCEP contact op met het NDES HTTPS-eindpunt. Voor apparaten die door Intune worden beheerd, wordt dit automatisch geactiveerd door een Intune SCEP-profiel. Het apparaat genereert een sleutelpaar en construeert een PKCS#10 Certificate Signing Request (CSR).

Stap 2: NDES geeft een uitdagingswachtwoord uit

NDES genereert een eenmalig wachtwoord (OTP) dat wordt gebruikt om het verzoek te valideren. In Intune-geïntegreerde implementaties autoriseert Intune het verzoek vooraf en verstrekt het de uitdaging via de NDES-connector, waardoor handmatige OTP-opvraging niet nodig is.

Stap 3: Apparaat dient certificaatverzoek in

Het apparaat verstuurt zijn certificaatondertekeningsverzoek samen met het uitdagingswachtwoord naar NDES via een HTTP POST-verzoek naar het SCEP-eindpunt. NDES valideert de uitdaging voordat het verzoek naar de certificeringsinstantie wordt doorgestuurd.

Stap 4: NDES dient de gegevens in bij de CA

NDES stuurt het verzoek door naar de Microsoft CA met behulp van de referenties van het NDES-serviceaccount en de aangewezen certificaatsjabloon. De CA beoordeelt het verzoek aan de hand van het beleid, het sleutelgebruik, de EKU en de subjectnaaminstellingen van de sjabloon voordat het certificaat wordt uitgegeven of geweigerd.

Stap 5: Certificaat wordt afgegeven

De certificeringsinstantie (CA) ondertekent het certificaat en stuurt het terug naar NDES. De uitgifte door de CA wordt vastgelegd in de CA-database en het gebeurtenislogboek. Dit is het punt waar de SIEM-integratie de uitgifte moet vastleggen voor auditdoeleinden.

Stap 6: Apparaat haalt certificaat op

Het apparaat peilt het NDES-eindpunt en haalt het ondertekende certificaat op. Het apparaat installeert het in de juiste certificaatopslag (machineopslag voor apparaatauthenticatie, gebruikersopslag voor gebruikerscertificaten). Het CLM-platform moet dit certificaat op dit punt in de inventaris registreren voor tracering en verlengingsbeheer.

Veelvoorkomende NDES-configuratiefouten die tijdens beveiligingsbeoordelingen worden aangetroffen

Bij PKI-beveiligingsbeoordelingen komen consistent verschillende NDES-configuratiefouten naar voren. Elk daarvan vormt een reële aanvalsvector.

1. NDES rechtstreeks blootgesteld aan het internet

NDES-eindpunten draaien vaak op IIS en kunnen onbeveiligd extern worden gepubliceerd. Dit stelt aanvallers in staat om certificaatregistratie te proberen, sjablonen te achterhalen en IIS-kwetsbaarheden te misbruiken. NDES moet altijd worden beschermd door toepassingsgateways en op rollen gebaseerde toegangsregels. Publiceer nooit de onbewerkte NDES-URL rechtstreeks op internet; routeer altijd via een reverse proxy of Azure Application Proxy die authenticatie kan afdwingen voordat verzoeken NDES bereiken.

2. Serviceaccounts met te veel privileges

NDES gebruikt een serviceaccount om certificaten aan te vragen bij de CA. Als dit account te veel machtigingen heeft, kunnen aanvallers die het account compromitteren zelfstandig certificaten uitgeven. Dit risico is bijzonder groot, omdat certificaten kunnen worden gebruikt voor authenticatie en laterale verplaatsing. Het NDES-serviceaccount mag alleen de machtiging 'Inschrijven' hebben voor de aangewezen SCEP-sjabloon, lokaal lidmaatschap van IIS_IUSRS en de rechten 'Aanmelden als service'. Het mag nooit lid zijn van de groepen 'Domeinbeheerders' of 'CA-beheerders'.

3. Zwakke sjabloonconfiguratie

Sjablonen die voor SCEP worden gebruikt, zijn soms zo geconfigureerd dat ze exporteerbare privésleutels toestaan, te ruime gebruiksrechten verlenen (bijvoorbeeld zowel client- als serverauthenticatie in hetzelfde sjabloon) en certificaten uitgeven zonder goedkeuring van de beheerder. Deze verkeerde configuraties kunnen leiden tot identiteitsfraude en misbruik van certificaten. Schakel de export van privésleutels altijd uit in SCEP-sjablonen. Stel de minimaal vereiste EKU in voor het gebruiksscenario. Overweeg om goedkeuring door de CA-beheerder in te schakelen voor sjablonen met hoge privileges, zelfs wanneer SCEP wordt gebruikt.

4. Gebrek aan monitoring en registratie

Veel organisaties implementeren NDES, maar monitoren het nooit. Zonder adequate monitoring en logging blijft de uitgifte van frauduleuze certificaten onopgemerkt, kan misbruik bij de inschrijving niet worden gedetecteerd en wordt incidentrespons lastig. Integreer CA-gebeurtenislogboeken (gebeurtenis-ID 4886 voor certificaataanvragen, gebeurtenis-ID 4887 voor certificaatuitgifte) met uw SIEM. Stel waarschuwingen in voor abnormale pieken in het inschrijvingsvolume afkomstig van één bron-IP-adres of apparaat. Gebruik CBOM Secure om een ​​continue cryptografische inventarisatie bij te houden van alle door NDES uitgegeven certificaten.

Beveiligingsrichtlijnen voor NDES-implementaties

Om NDES in moderne omgevingen te beveiligen, dienen organisaties deze best practices te volgen. Zie voor meer informatie de bijbehorende handleiding: Best practices voor NDES-beveiliging.

1. Isoleer NDES-servers

NDES mag nooit rechtstreeks op de CA worden geïnstalleerd. Implementeer het in een speciaal DMZ-segment, achter een reverse proxy of applicatiegateway, met beperkte netwerktoegang tot de CA (alleen CA RPC-poorten, geblokkeerd voor alle andere interne segmenten). Dit beperkt de impact als de NDES-server wordt gehackt.

2. Beperk de sjabloonrechten

SCEP-sjablonen moeten alleen de vereiste EKU's toestaan, de formaten van onderwerpnamen beperken tot 'Supply' in het verzoek (gevalideerd via NDES-uitdaging), het exporteren van privésleutels uitschakelen en inschrijvingsrechten alleen instellen voor het NDES-serviceaccount in plaats van voor alle domeincomputers.

3. Toezicht houden op de uitgifte van certificaten

Registreer alle SCEP-aanvragen via IIS-logboeken en CA-gebeurtenislogboeken. Monitor het sjabloongebruik op basis van sjabloonnaam en aanvragend account. Geef een waarschuwing bij abnormale aantallen aanmeldingen (bijvoorbeeld meer dan 50 certificaataanvragen per uur van één bron). Dit is vooral belangrijk voor sjablonen die authenticatiecertificaten voor clients verstrekken, omdat deze, indien in handen van een aanvaller, kunnen worden gebruikt voor laterale verplaatsing.

4. IIS-configuratie beveiligen

Omdat NDES op IIS draait, moet u ongebruikte IIS-modules uitschakelen, TLS 1.2 of hoger afdwingen voor de HTTPS-binding van NDES, HTTPS-beveiligingsheaders (HSTS, X-Content-Type-Options, X-Frame-Options) toepassen en de server regelmatig patchen. De NDES IIS-site moet de enige site op de server zijn; plaats geen andere applicaties op dezelfde server.

Waar SCEP en NDES beperkingen beginnen te vertonen

Ondanks hun wijdverbreide toepassing waren SCEP en NDES oorspronkelijk niet ontworpen voor de huidige cloudomgevingen. Bij moderne implementaties doen zich vaak verschillende uitdagingen voor.

Beperkte beveiligingscontext

SCEP is ontworpen met eenvoud als uitgangspunt, wat betekent dat het beperkte mogelijkheden biedt voor identiteitsvalidatie. Het uitdagingswachtwoordmechanisme is een gedeeld geheim, geen cryptografisch identiteitsbewijs. Vaak moeten er extra controles worden toegevoegd (zoals de pre-autorisatie van Intune via de NDES Connector) om een ​​sterke apparaatauthenticatie te garanderen voordat certificaten worden uitgegeven.

Operationele complexiteit

NDES-implementaties vereisen dedicated servers, IIS-beveiliging, netwerkblootstellingsplanning, sjabloonconfiguratiebeheer en beheer van de levenscyclus van serviceaccounts. In hybride of multi-cloudomgevingen met meerdere NDES-instanties leidt dit tot aanzienlijke operationele overhead zonder uniforme CLM-tools die inzicht bieden in alle instanties.

Uitdagingen schalen

Hoewel SCEP goed werkt voor eindapparaten, is het minder geschikt voor dynamische workloads zoals containers, microservices of tijdelijke cloud-instanties. Deze moderne workloads vereisen snellere certificaatuitgiftecycli, sterkere mechanismen voor identiteitsverificatie en kortstondige certificaten. ACME pakt deze scenario's effectiever aan.

Het moderne framework voor certificeringsautomatisering: ACME

ACME (Automated Certificate Management Environment) is ontwikkeld om volledig geautomatiseerd beheer van de certificaatlevenscyclus mogelijk te maken met minimale menselijke tussenkomst. In tegenstelling tot SCEP is ACME gebouwd voor moderne omgevingen en ondersteunt het geautomatiseerde uitgifte en verlenging van certificaten, API-gestuurde workflows, identiteitsverificatiemechanismen en kortstondige certificaten die aansluiten bij de Zero Trust-principes.

ACME is met name waardevol voor DevOps-pipelines, Kubernetes-clusters, cloud-native services en service-to-service-authenticatie. Bedrijven gebruiken het steeds vaker intern voor workload-identiteiten, naast SCEP/NDES voor apparaatcertificaten.

Een vergelijking tussen SCEP, NDES en ACME in Enterprise PKI.

Elke technologie dient een ander doel. Organisaties gebruiken ze vaak samen in plaats van er slechts één te kiezen.

Afmeting	SCEP / NDES	ACME	AD-automatische inschrijving
Primair gebruiksgeval	Apparaatcertificaten voor Intune-beheerde eindpunten, VPN-clients, IoT-apparaten en netwerkapparatuur.	Server- en workloadcertificaten voor DevOps-pipelines, Kubernetes en cloud-native services.	Gebruikers- en computercertificaten voor Windows-systemen die lid zijn van een domein.
Apparaatvereiste:	Vereist geen Active Directory-lidmaatschap; gebruikt een uitdagingswachtwoord voor authenticatie.	Vereist geen Active Directory; maakt gebruik van domeinvalidatie of API-tokenauthenticatie.	Vereist Active Directory-lidmaatschap en Groepsbeleid.
Levenslang geldig certificaat	Ondersteunt apparaatcertificaten met een langere geldigheidsduur (doorgaans 1 jaar); verlenging via een nieuw SCEP-verzoek.	Ontworpen voor kortdurende certificaten (enkele dagen tot 90 dagen); automatische verlenging ingebouwd in het protocol.	Ondersteunt elke geldigheidsperiode die in de sjabloon is geconfigureerd; verlenging via automatische inschrijving via GPO.
Benodigde infrastructuur	NDES-server (dedicated Windows Server + IIS), NDES-serviceaccount, CA RPC-toegang	ACME-compatibel CA-eindpunt; geen aparte server nodig naast de CA zelf.	Domeincontroller, Groepsbeleid, CA die lid is van het domein
Cloud-/hybride ondersteuning	Werkt met Intune via de NDES-connector; vereist een on-premises NDES-server voor on-premises ADCS.	Native voor cloud CA's; werkt zonder on-premises infrastructuur.	Vereist een on-premises Active Directory; niet geschikt voor cloudgebaseerde of BYOD-apparaten.
PQC-gereedheid	Beperkt; afhankelijk van CA en sjabloonalgoritmeconfiguratie; geen ingebouwde algoritmeonderhandeling	Robuust; algoritme-onderhandeling ingebouwd in het protocol; klaar voor migratie naar NIST FIPS 203/204/205.	Afhankelijk van de CA-sjabloonconfiguratie; vereist een sjabloonupdate voor PQC-algoritmen.
Best voor	Intune-apparaatcertificaten, VPN-certificaten, Wi-Fi-certificaten, IoT-apparaatidentiteit	Webserver TLS, containeridentiteit, CI/CD-pipelinecertificaten, kortstondige servicecertificaten	Certificaten voor Windows-gebruikers en -computers die lid zijn van een domein.

Praktisch voorbeeld: hybride bedrijfsimplementatie

Neem bijvoorbeeld een bedrijf dat Zero Trust implementeert en tegelijkertijd naar de cloud migreert. Ze zouden NDES, geïntegreerd met Intune, kunnen inzetten voor het beheer van apparaatcertificaten, ACME-gebaseerde uitgifte voor containerworkloads en ADCS-automatische inschrijving voor interne servers. Dit hybride model stelt hen in staat om compatibiliteit met bestaande systemen te behouden en tegelijkertijd het beheer van de certificaatlevenscyclus te moderniseren. Het vermindert ook de afhankelijkheid van wachtwoorden en versterkt de op identiteit gebaseerde toegangscontrole in de hele omgeving.

Hoe kies je de juiste inschrijfmethode?

Als u zich richt op eindgebruikersapparaten of netwerkapparaten die geen lid kunnen worden van Active Directory, blijft SCEP met NDES een praktische en breed ondersteunde oplossing. Als u zich richt op moderne workloads of omgevingen met veel automatisering, biedt ACME een sterkere integratie en schaalbaarheid. Als u domein-gekoppelde Windows-systemen beheert met Groepsbeleid, is automatische AD-inschrijving de meest efficiënte methode.

De meeste bedrijven zullen alle drie nodig hebben tijdens hun overgang naar cloud-native beveiligingsmodellen. Een uniform CLM-platform zoals CertSecure Manager biedt één centraal overzicht van alle drie uitgifteprocessen, waardoor geen enkel certificaat uit de inventaris verdwijnt, ongeacht hoe het is uitgegeven.

Inschrijving voor het certificaatprogramma 'De toekomst van ondernemerschap'

Authenticatie op basis van certificaten wordt in hoog tempo het standaardmechanisme voor het beveiligen van bedrijfsomgevingen. Naarmate organisaties overstappen op wachtwoordloze authenticatie, het afdwingen van apparaatidentiteit, Zero Trust-toegangsmodellen en cloud-native architectuur, wordt certificaatautomatisering een essentiële beveiligingsfunctionaliteit in plaats van een nichefunctie van de PKI (Public Key Infrastructure).

SCEP en NDES zullen waarschijnlijk in gebruik blijven voor apparaatregistratie, terwijl de adoptie van ACME blijft groeien voor workload-identiteiten en infrastructuurautomatisering. NIST heeft FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) en FIPS 205 (SLH-DSA) in augustus 2024 afgerond. Organisaties die nog niet zijn begonnen met de PQC-gereedheidsplanning, moeten de CA-algoritmeprofielen en certificaatsjablonen bijwerken om post-quantumalgoritmen te ondersteunen. Begin met de PQC-gereedheidsbeoordeling en het PQC Center of Excellence voor een NIST-gealigneerde migratieplanning.

Hoe encryptieconsultancy kan helpen

Encryption Consulting heeft ruime ervaring met het leveren van complete PKI-oplossingen voor bedrijven en overheidsinstellingen. We bieden zowel professionele diensten als ons automatiseringsplatform ( CertSecure Manager ) om ervoor te zorgen dat uw PKI veilig, robuust en toekomstbestendig is.

PKI-diensten

Complete advies-, ontwerp- en implementatiediensten om organisaties te helpen bij het bouwen, moderniseren en beheren van veilige Public Key Infrastructure-omgevingen.

Project planning

We beoordelen uw cryptografische omgeving, bekijken PKI-configuraties, afhankelijkheden en vereisten, en bundelen de bevindingen in een gestructureerd, door de klant goedgekeurd projectplan.

CP/CPS-ontwikkeling

Wij ontwikkelen een certificeringsbeleid (CP) en een certificeringspraktijkverklaring (CPS) die aansluiten op RFC 3647. Deze documenten worden aangepast aan de wettelijke, beveiligings- en operationele eisen van uw organisatie.

PKI-ontwerp en -implementatie

Wij ontwerpen en implementeren robuuste PKI-infrastructuren, inclusief offline root-CA's, uitgevende CA's, NDES-servers en HSM-integratie, afhankelijk van de behoeften van de klant. De oplevering omvat een PKI-ontwerpdocument, implementatiehandleidingen, scripts voor de ceremonie en systeemconfiguraties. Na de implementatie voeren we grondige tests, validatie, finetuning en kennisoverdrachtsessies uit om uw team te ondersteunen.

Bedrijfscontinuïteit en Rampherstel

Na de implementatie ontwikkelen en implementeren we strategieën voor bedrijfscontinuïteit en noodherstel, voeren we failover-tests uit en documenteren we operationele workflows voor de gehele PKI- en HSM-infrastructuur, ondersteund door een uitgebreide handleiding voor PKI-beheer.

Doorlopende ondersteuning en onderhoud (optioneel)

Na de implementatie bieden we een jaarlijks ondersteuningspakket op abonnementsbasis aan, dat uitgebreide dekking biedt voor PKI-, CLM- en HSM-componenten. Dit omvat incidentafhandeling, probleemoplossing, systeemoptimalisatie, certificaatlevenscyclusbeheer, CP/CPS-updates, sleutelarchivering, HSM-firmware-upgrades, auditregistratie en patchbeheer.

Met deze aanpak bent u ervan verzekerd dat uw PKI-infrastructuur niet alleen veilig en conform is, maar ook schaalbaar, veerkrachtig en volledig afgestemd op uw operationele en wettelijke doelstellingen op de lange termijn.

CertSecure Manager

CertSecure Manager van Encryption Consulting is een oplossing voor certificaatlevenscyclusbeheer die de gehele levenscyclus vereenvoudigt en automatiseert, zodat u zich kunt concentreren op beveiliging in plaats van op verlengingen.

• Automatisering voor kortlopende certificaten: Nu ACME- en 90-dagen/47-dagen TLS-certificaten de standaard zijn geworden, is handmatige verlenging geen praktische optie meer. CertSecure Manager automatiseert de inschrijving, verlenging en implementatie, zodat certificaten nooit ongemerkt verlopen.
• Naadloze DevOps- en cloudintegratie: Certificaten kunnen rechtstreeks in webservers en cloud-instanties worden geïnstalleerd en integreren met moderne logboekregistratietools zoals Datadog en Splunk, ITSM-tools zoals ServiceNow en DevOps-tools zoals Terraform en Ansible.
• Ondersteuning voor meerdere CA's: Veel organisaties maken gebruik van meerdere certificeringsinstanties (CA's) (interne Microsoft CA, openbare CA's zoals DigiCert en GlobalSign, enz.). CertSecure Manager integreert deze bronnen en biedt één overzichtelijk dashboard voor uitgifte en lifecyclemanagement binnen de SCEP/NDES- en ACME-registratieprocessen.
• Uniform uitgifte- en verlengingsbeleid: CertSecure Manager zorgt ervoor dat de sleutelgroottes, algoritmen en verlengingsregels van uw organisatie consistent worden toegepast op alle certificaten, zodat elk certificaat te allen tijde aan uw beveiligingsnormen voldoet.
• Proactieve monitoring en vernieuwingstesten: Continue monitoring, gecombineerd met gesimuleerde verlengings- en vervaldatumtests, zorgt ervoor dat u risico's identificeert voordat certificaten de productiesystemen beïnvloeden.
• Gecentraliseerde zichtbaarheid en naleving: Eén overzichtelijk dashboard toont alle certificaten, sleutellengtes, sterke en zwakke algoritmen en hun vervaldatums. Auditlogboeken en beleidshandhaving vereenvoudigen de naleving van de regelgeving. PCI DSS, HIPAAen andere raamwerken.

Als u zich afvraagt ​​waar u moet beginnen met het beveiligen van uw PKI, dan staat Encryption Consulting voor u klaar met haar PKI-ondersteuningsdiensten . U kunt op ons rekenen als uw betrouwbare partner en wij begeleiden u bij elke stap met duidelijkheid, vertrouwen en praktijkervaring.

Conclusie

Enterprise PKI evolueert van een backend-beveiligingstool naar een centrale identiteitsinfrastructuur. Inzicht in de interactie tussen SCEP, NDES en ACME stelt organisaties in staat schaalbare certificaatbeheerpipelines te bouwen die zowel legacy-omgevingen als moderne cloudworkloads ondersteunen. Door traditionele PKI-principes te combineren met moderne automatiseringsframeworks kunnen bedrijven overstappen op sterkere identiteitsgestuurde beveiliging zonder in te boeten aan operationele efficiëntie.

NDES blijft essentieel voor hybride Intune-implementaties en certificaatinschrijving voor apparaten buiten het domein, maar het moet met dezelfde zorgvuldigheid worden geïmplementeerd en beveiligd als de CA zelf. Beschouw elke verkeerd geconfigureerde NDES-server als een potentiële achterdeur voor certificaatuitgifte. Investeer in CLM-tools om volledig inzicht te behouden in door NDES uitgegeven certificaten en begin nu met de voorbereiding op PQC, zodat algoritme-overgangen geen noodherstel van de CA vereisen wanneer wettelijke deadlines naderen.

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit NDES en SCEP uitgelegd: De ruggengraat van geautomatiseerde certificaatinschrijving?

SCEP blijft het de facto protocol voor geautomatiseerde certificaatverwerving voor apparaten in Microsoft PKI-omgevingen, en NDES is de vereiste brug tussen SCEP-compatibele apparaten en ADCS. Zonder NDES kunnen Intune, MDM-platforms en apparaten die geen deel uitmaken van een domein geen certificaten verkrijgen van een lokale CA. Verkeerd geconfigureerde NDES-servers zijn een van de meest voorkomende kwetsbaarheden in PKI-systemen en moeten met dezelfde beveiligingsdiscipline worden behandeld als de CA zelf.

Waarom zijn NDES en SCEP belangrijk voor PKI-teams binnen bedrijven?

Enterprise PKI-teams zijn verantwoordelijk voor de certificaatinfrastructuur waarop Intune, MDM, VPN, Wi-Fi en Zero Trust-toegangssystemen vertrouwen. NDES is de manier waarop deze systemen certificaten verkrijgen van ADCS voor apparaten die geen deel uitmaken van een domein. Volgens de Trust Pulse Survey van DigiCert (2 juli 2025) heeft bijna de helft van de bedrijven het afgelopen jaar te maken gehad met downtime als gevolg van certificaatproblemen. Een verkeerd geconfigureerde of niet-beschikbare NDES-server kan de apparaatauthenticatie in een hele organisatie tegelijkertijd verstoren.

Welke risico's nemen toe als NDES en SCEP niet goed beveiligd zijn?

De risico's omvatten: een via internet toegankelijk NDES-eindpunt stelt aanvallers in staat certificaatsjablonen te achterhalen en ongeautoriseerde registratie te proberen; een serviceaccount met te hoge privileges stelt aanvallers in staat zich voor te doen als dit account en zelfstandig certificaten uit te geven; een zwakke sjabloonconfiguratie met exporteerbare privésleutels creëert kwetsbaarheden voor identiteitsfraude; en het ontbreken van monitoring betekent dat de uitgifte van frauduleuze certificaten onopgemerkt blijft totdat er een incident plaatsvindt.

Welke teams moeten verantwoordelijk zijn voor de implementatie en beveiliging van NDES en SCEP?

PKI-beheerders zijn verantwoordelijk voor de implementatie van de NDES-server, de configuratie van certificaatsjablonen en het CA-beleid. Beveiligingsarchitecten zijn verantwoordelijk voor het ontwerp van de netwerkisolatie en de IIS-beveiligingsnormen. Platform- en endpointteams zijn verantwoordelijk voor de MDM/Intune-integratie en de profielen voor apparaatregistratie. Complianceteams zijn verantwoordelijk voor de vereisten voor auditlogboeken en het verzamelen van bewijsmateriaal voor monitoring. CISO's zijn verantwoordelijk voor de vermelding van NDES in het risicoregister als een belangrijk aanvalsoppervlak, gezien de rol ervan bij de uitgifte van certificaten voor authenticatie.

Hoe zijn NDES en SCEP gekoppeld aan certificaatlevenscyclusbeheer?

NDES en SCEP verzorgen de initiële certificaatregistratie en verlengingsverzoeken van apparaten. Certificaatlevenscyclusbeheer (CLM) biedt de bredere operationele laag die alle certificaten in de omgeving volgt, bewaakt en beheert. CertSecure Manager integreert met de SCEP/NDES-registratieprocessen en biedt een uniform overzicht van ADCS-certificaten, openbare CA-certificaten en cloudcertificaten in één dashboard met geautomatiseerde waarschuwingen voor verlopen certificaten en verlengingsworkflows.

Hoe moeten organisaties het succes meten na de implementatie van NDES?

Belangrijke meetwaarden zijn onder meer: ​​het percentage doelapparaten dat succesvol is ingeschreven via SCEP/NDES (doel: 100% van de MDM-beheerde apparaten); het aantal mislukte SCEP-inschrijvingspogingen per week (doel: naar nul toe na initiële stabilisatie); het aantal authenticatiefouten per kwartaal als gevolg van verlopen certificaten uitgegeven door NDES (doel: nul); de tijd die nodig is om een ​​frauduleus of ongeautoriseerd certificaat uitgegeven via NDES te detecteren (doel: dezelfde dag via SIEM-waarschuwing); en de beschikbaarheid van de NDES-server (doel: minimaal 99.9%).

Wat moet er regelmatig gecontroleerd of gemonitord worden bij een NDES-implementatie?

Continue monitoring: volume en foutpercentage van SCEP-aanmeldingsverzoeken; via NDES uitgegeven certificaten in de CA-database; status van de NDES IIS-applicatiepool; en netwerktoegang tot het NDES-eindpunt vanaf onverwachte bron-IP-adressen. Kwartaalcontrole: naleving van de NDES-serviceaccountmachtigingen volgens de vereisten voor minimale bevoegdheden; certificaatsjabloonconfiguratie voor SCEP; IIS-configuratie voor TLS-versiehandhaving; en patchniveau van het NDES-serverbesturingssysteem.

Welke invloed heeft NDES op cloud-, hybride- of multi-CA-omgevingen?

In hybride omgevingen waar Intune zowel cloud-native als on-premises apparaten beheert, is NDES de vereiste brug voor het uitgeven van certificaten vanuit on-premises ADCS naar cloud-beheerde apparaten. In omgevingen met meerdere certificeringsinstanties (CA's) kunnen organisaties meerdere NDES-instanties gebruiken. Zonder CLM-tools die een uniform overzicht bieden, creëren certificaten die door verschillende NDES-instanties bij verschillende CA's zijn uitgegeven blinde vlekken in de inventaris. CBOM Secure automatiseert cryptografische detectie in deze hybride omgevingen om een ​​complete en controleerbare certificaatinventaris te behouden.

Welke voorwaarden zijn vereist voordat NDES kan worden ingezet?

De vereisten omvatten: een werkende ADCS-omgeving met ten minste één uitgevende CA; Windows Server 2016 of later voor de NDES-rol; een speciaal serviceaccount met CA-inschrijvingsrechten en IIS-toegang (geen domeinbeheerder); een certificaatsjabloon geconfigureerd voor SCEP-inschrijving met correct sleutelgebruik (digitale handtekening), EKU en zonder exporteerbare privésleutels; IIS geïnstalleerd op de NDES-server; en een geldig SSL-certificaat voor het NDES HTTPS-eindpunt. NDES mag niet op de CA-server zelf geïnstalleerd zijn.

Welke veelvoorkomende fouten moeten beheerders in de gaten houden bij de implementatie van NDES?

Veelvoorkomende fouten zijn onder andere: HTTP 403 op de NDES-URL als gevolg van IIS-machtigingen of problemen met de identiteit van de toepassingsgroep; mislukte pogingen om het uitdagingswachtwoord op te halen als gevolg van het ontbreken van CA-inschrijvingsmachtigingen voor het NDES-serviceaccount; afwijzingen van certificaatverzoeken als gevolg van een verkeerde sjabloonconfiguratie of een ontbrekende EKU; het vastlopen van de NDES-toepassingsgroep als gevolg van geheugen- of IIS-moduleproblemen; en apparaten die het NDES SSL-certificaat niet kunnen vertrouwen omdat de uitgevende CA niet in de vertrouwensarchief van het apparaat staat.