NDES und SCEP erklärt: Das Rückgrat der automatisierten Zertifikatsregistrierung

Da Unternehmen die Einführung von Zero Trust, Geräteauthentifizierung und Cloud-basierter Infrastruktur beschleunigen, ist die herkömmliche manuelle Zertifikatsregistrierung nicht mehr skalierbar. Ob es um die Einbindung Tausender Laptops über Intune, die Ausstellung von Zertifikaten für den VPN-Zugang oder die Aktivierung der WLAN-Authentifizierung in globalen Niederlassungen geht – die automatisierte Zertifikatsregistrierung ist unerlässlich.

Hier spielen SCEP (Simple Certificate Enrollment Protocol) und NDES (Network Device Enrollment Service) eine entscheidende Rolle in Microsoft-PKI-Ökosystemen. Trotz ihrer Bedeutung setzen viele Administratoren sie ein, ohne ihre Funktionsweise, Unterschiede oder die korrekte Absicherung vollständig zu verstehen. Fehlkonfigurierte NDES-Server zählen nach wie vor zu den häufigsten PKI- Schwachstellen, die bei Sicherheitsaudits aufgedeckt werden.

Kurzantwort: Was sind NDES und SCEP?

SCEP (Simple Certificate Enrollment Protocol) ermöglicht es Geräten, Zertifikate über HTTP/HTTPS anzufordern, ohne Active Directory beitreten zu müssen. NDES (Network Device Enrollment Service) ist Microsofts Implementierung von SCEP und fungiert als Schnittstelle zwischen SCEP-fähigen Geräten und ADCS. Ohne NDES können Intune- und MDM-Plattformen keine Zertifikate von einer lokalen Zertifizierungsstelle ausstellen.

Wichtige Erkenntnisse

• NDES ist die notwendige Schnittstelle zwischen SCEP-fähigen Geräten (Intune-verwaltete Endpunkte, IoT-Geräte, VPN-Gateways, Netzwerkgeräte) und Microsoft ADCS. Ohne NDES können diese Geräte keine Zertifikate von einer lokalen Zertifizierungsstelle beziehen.
• Fehlkonfigurierte NDES-Server stellen eine der am häufigsten ausgenutzten Angriffsflächen für PKI-Systeme dar. Ein mit dem Internet verbundener NDES-Endpunkt, ein übermäßig privilegiertes Dienstkonto oder eine schwache Zertifikatvorlage können jeweils unabhängig voneinander zur unautorisierten Zertifikatsausstellung führen.
• Laut der DigiCert Trust Pulse-Umfrage (2. Juli 2025) erlebte fast die Hälfte aller Unternehmen im vergangenen Jahr Ausfallzeiten im Zusammenhang mit Zertifikaten. Ein falsch konfigurierter oder nicht verfügbarer NDES-Server unterbricht die Geräteauthentifizierung im gesamten Unternehmen gleichzeitig.
• Die Abstimmung SC-081v3 des CA/Browser Forums (April 2025) reduziert die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate bis März 2029 auf 47 Tage. Dies macht die automatisierte SCEP/NDES-Registrierung und CLM-Tools unerlässlich; eine manuelle Erneuerung kann diesen Rhythmus bei einer so großen Geräteflotte nicht unterstützen.
• SCEP und NDES werden nicht durch ACME ersetzt; sie decken unterschiedliche Anwendungsfälle ab. SCEP/NDES verwaltet Gerätezertifikate für Intune, VPN und Netzwerkgeräte. ACME verwaltet Server- und Workload-Zertifikate für DevOps-Pipelines, Kubernetes und Cloud-native Dienste. Die meisten Unternehmen benötigen beides.

Wer sollte sich für NDES und SCEP interessieren?

Die Implementierung und Sicherheit von NDES ist eine abteilungsübergreifende Aufgabe. Jede der unten aufgeführten Rollen trägt ein direktes Interesse an einem erfolgreichen Ergebnis.

Funktion / Rolle (Role) *	Warum es wichtig ist	Aktionselement
PKI-Administratoren	Eigene NDES-Serverbereitstellung, Konfiguration von Zertifikatvorlagen für SCEP, Einrichtung des CA-Registrierungsagenten und Durchsetzung der CA-Richtlinien für von NDES ausgestellte Zertifikate	NDES auf einem dedizierten Server (nicht der Zertifizierungsstelle) bereitstellen; Vorlagen mit korrekter Schlüsselverwendung, EKU und ohne exportierbare private Schlüssel konfigurieren; Ausstellungsprotokolle der Zertifizierungsstelle in SIEM integrieren
Sicherheitsarchitekten	Sie sind verantwortlich für das Netzwerkisolationsdesign, die IIS-Härtungsstandards und das NDES-Dienstkonto-Berechtigungsmodell, die die Angriffsfläche der NDES-Bereitstellung bestimmen.	Platzieren Sie NDES in einer DMZ hinter einem Reverse-Proxy oder Application Gateway; erzwingen Sie das Prinzip der minimalen Berechtigungen für das NDES-Dienstkonto; definieren Sie Zertifikatvorlagen-ACLs, die die SCEP-Registrierung auf autorisierte Geräte beschränken.
Plattform-/Endpunkt-Teams	Besitzen Sie die Intune-, MDM- und Geräteverwaltungsintegration, die für die Zertifikatszustellung an verwaltete Geräte auf NDES angewiesen ist.	Konfigurieren Sie Intune SCEP-Profile, die auf den NDES-HTTPS-Endpunkt verweisen; testen Sie die Zertifikatsbereitstellung für verschiedene Gerätetypen (Windows, iOS, Android, macOS); stellen Sie sicher, dass der Truststore des Geräts die Stammzertifizierungsstelle enthält.
Compliance-Teams	Es muss nachgewiesen werden, dass die Zertifikatsausstellung über NDES protokolliert, überwacht und auditierbar ist; NDES ist ein kritischer Kontrollpunkt für zertifikatsbasierte Authentifizierungsnachweise.	Sicherstellen, dass die CA-Ausstellungsprotokolle alle SCEP-registrierten Zertifikate erfassen; NDES-IIS-Protokolle in SIEM integrieren; NDES-ausgestellte Zertifikate in das vierteljährliche Zertifikatsinventar und den Prüfungsbereich aufnehmen
CISOS	Behalten Sie den Risikoregistereintrag für NDES als wertvolle Angriffsfläche im Auge, denn eine Kompromittierung von NDES ermöglicht die unautorisierte Ausstellung von Zertifikaten, die zur Authentifizierung und lateralen Bewegung genutzt werden können.	NDES soll in jedes PKI-Sicherheitsaudit einbezogen werden; CLM-Tools für die einheitliche Transparenz von NDES-ausgestellten Zertifikaten sollen finanziert werden; die Verfügbarkeit von NDES soll in die Berichterstattung zur PKI-Resilienz aufgenommen werden.

Was ist SCEP?

SCEP (Simple Certificate Enrollment Protocol ) ist ein ursprünglich von Cisco entwickeltes Protokoll zur Automatisierung der Zertifikatsregistrierung für Netzwerkgeräte, die nicht ohne Weiteres in Active Directory eingebunden werden können. Im Gegensatz zu herkömmlichen AD-basierten Registrierungsmethoden ermöglicht SCEP Geräten, Zertifikate über HTTP/ HTTPS anzufordern , sich mit einem gemeinsamen Geheimnis oder einem Challenge-Passwort zu authentifizieren und signierte Zertifikate automatisch abzurufen.

SCEP wurde für Geräte wie Router und Switches, VPN-Gateways, Netzwerkgeräte, IoT-Geräte und Mobilgeräte entwickelt. Im Laufe der Zeit hat es sich zum De-facto-Standard für die Zertifikatsregistrierung in Geräteverwaltungsplattformen, einschließlich Microsoft Intune und vielen MDM-Lösungen , entwickelt.

Was ist eine Nahtoderfahrung?

NDES (Network Device Enrollment Service) ist Microsofts Implementierung von SCEP. Es fungiert als Schnittstelle zwischen Geräten und der Microsoft-Zertifizierungsstelle und ermöglicht es Geräten, die sich nicht über Active Directory authentifizieren können, dennoch sicher Zertifikate zu erhalten. Ohne NDES ist SCEP nicht mit Microsoft ADCS nutzbar.

Vereinfacht ausgedrückt funktioniert es so:

1. Die Geräte kommunizieren über SCEP mit NDES.
2. NDES validiert die Anfrage
3. NDES leitet die Anfrage an Microsoft CA weiter.
4. Die Zertifizierungsstelle stellt das Zertifikat aus
5. NDES sendet es zurück an das Gerät.

Voraussetzungen vor der Bereitstellung von NDES

Vor der Bereitstellung von NDES stellen Sie bitte sicher, dass alle folgenden Voraussetzungen erfüllt sind. Fehlende Voraussetzungen sind die häufigste Ursache für Installationsfehler und Registrierungsfehler nach der Bereitstellung.

Voraussetzung	Anforderung	Validierungsprüfung	Häufiger Fehler bei fehlender	Eigentümer
ADCS-Umgebung	Mindestens eine ausstellende Zertifizierungsstelle, die unter Windows Server 2012 R2 oder höher ausgeführt wird; die Stammzertifizierungsstelle muss für die Validierung der Zertifizierungskette zugänglich sein.	Führen Sie certutil -ping gegen die Zertifizierungsstelle vom NDES-Server, um die RPC-Konnektivität zu bestätigen.	Die NDES-Einrichtung schlägt während der Konfiguration mit der Fehlermeldung „Die Zertifizierungsstelle ist nicht erreichbar“ fehl.	PKI-Administrator
Dedizierter NDES-Server	Windows Server 2016 oder höher; NDES darf NICHT auf dem CA-Server selbst installiert werden; IIS muss vor der NDES-Rolle installiert werden.	Stellen Sie sicher, dass der Server der Domäne beigetreten ist und die IIS-Standardwebsite ausgeführt wird, bevor Sie die NDES-Rolle installieren.	Bei Installation auf einer Zertifizierungsstelle (CA) kommt es zu Konflikten mit den RPC-Listenern der CA; die Installation kann zwar erfolgreich sein, die Registrierung schlägt jedoch zur Laufzeit fehl.	PKI-Administrator
NDES-Dienstkonto	Dediziertes Domänenkonto (kein Domänenadministratorkonto); muss Mitglied der lokalen IIS_IUSRS-Gruppe sein; muss über die Berechtigung „Registrieren“ für die SCEP-Zertifikatvorlage verfügen; muss über das Recht „Anmelden als Dienst“ verfügen.	Bestätigen Sie, dass das Konto kein Mitglied der Domänenadministratoren ist; bestätigen Sie die Registrierung der Zugriffssteuerungs-Execution (ACE) auf der Registerkarte „Sicherheit“ der Vorlage.	HTTP 500-Fehler bei NDES-URL oder Fehler beim Abrufen des Challenge-Passworts, wenn dem Konto die CA-Registrierungsrechte fehlen	PKI-Administrator / Sicherheitsarchitekt
Zertifikatvorlage	Vorlage für SCEP konfiguriert: Schlüsselverwendung = Digitale Signatur; EKU = Client-Authentifizierung (und weitere nach Bedarf); privater Schlüssel nicht exportierbar; Subjektname in der Anfrage angeben	Öffnen Sie die Vorlage in certtmpl.msc; überprüfen Sie die Einstellungen für Schlüsselverwendung, EKU und privaten Schlüssel; vergewissern Sie sich, dass die Vorlage auf der ausstellenden Zertifizierungsstelle veröffentlicht ist.	Die Zertifikatsanfrage wurde von der Zertifizierungsstelle abgelehnt, da die Vorlagen-EKU nicht dem Verwendungszweck entspricht; NDES sendet HTTP 400 an das anfragende Gerät zurück.	PKI-Administrator
SSL-Zertifikat für NDES HTTPS-Endpunkt	Ein gültiges SSL/TLS-Zertifikat, das an die NDES-IIS-Website gebunden ist, ist erforderlich; die ausstellende Zertifizierungsstelle muss von allen Geräten, die NDES verwenden, als vertrauenswürdig eingestuft werden; TLS 1.2 oder höher wird erzwungen.	Rufen Sie die NDES-HTTPS-URL von einem Testgerät aus auf und vergewissern Sie sich, dass keine Zertifikatswarnung angezeigt wird; überprüfen Sie die IIS-Bindungen in inetmgr.	Geräte lehnen die NDES-Verbindung ab, wenn das SSL-Zertifikat selbstsigniert ist oder von einer nicht vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde; Intune meldet einen Registrierungsfehler.	PKI-Administrator-/Plattformteam
Netzwerkzugang	Die Geräte müssen den NDES-HTTPS-Endpunkt über TCP 443 erreichen; der NDES-Server muss die Zertifizierungsstelle über TCP 135 und dynamische RPC-Ports erreichen; für internetseitige Bereitstellungen wird ein Reverse-Proxy oder ein Application Gateway empfohlen.	Führen Sie Test-NetConnection -ComputerName ndes.contoso.com -Port 443 von einem Testgerät aus; bestätigen Sie, dass die Firewall-Regeln CA-RPC vom NDES-Server zulassen.	Registrierungs-Timeouts oder TCP-Reset-Fehler auf Geräten, wenn die Firewall NDES HTTPS blockiert; stille CA-Übermittlungsfehler, wenn NDES die CA nicht über RPC erreichen kann	Sicherheitsarchitekt / Netzwerkteam

Warum NDES in der modernen PKI immer noch wichtig ist

Manche Administratoren gehen davon aus, dass SCEP veraltet ist, weil es vor Jahrzehnten entwickelt wurde. Tatsächlich hat die Nutzung von SCEP aufgrund moderner Trends im Gerätemanagement jedoch dramatisch zugenommen. Die folgenden drei Anwendungsfälle verdeutlichen, warum NDES auch heute noch unverzichtbar ist.

1. Microsoft Intune-Gerätezertifikatregistrierung

Organisationen, die Intune einsetzen, verwenden häufig NDES zur Ausstellung von Geräteauthentifizierungszertifikaten, WLAN-Zertifikaten, VPN-Zertifikaten und E-Mail-Authentifizierungszertifikaten. Ohne NDES kann Intune keine Zertifikate von lokalen ADCS-Systemen ausstellen. Daher ist NDES eine Voraussetzung für jede hybride Intune-Bereitstellung, die auf einer internen Zertifizierungsstelle anstatt einer Cloud-basierten CA basiert.

2. Client-Authentifizierungszertifikate

NDES wird häufig zur Ausstellung von Client-Authentifizierungszertifikaten für Windows Always-On VPN, VPN-Clients von Drittanbietern und hybride Remote-Zugriffsarchitekturen verwendet. Dies ermöglicht eine passwortlose VPN-Authentifizierung, die an die Geräteidentität gekoppelt ist und eine grundlegende Kontrollfunktion in Zero-Trust-Netzwerkzugriffsmodellen darstellt.

3. IoT- und Netzwerkgeräteregistrierung

NDES ermöglicht die Ausstellung von Zertifikaten für Drucker, Kameras, Fertigungssysteme und Netzwerkgeräte. Da diese Geräte häufig nicht in Active Directory integriert werden können, ist SCEP die einzige skalierbare Option. In OT- und Industrieumgebungen mit Tausenden von Geräten bietet PKIaaS-basiertes NDES oder PKI-as-a-Service die erforderliche skalierbare Ausstellungsinfrastruktur.

Funktionsweise von NDES: Architekturübersicht

Eine typische NDES-Implementierung umfasst vier Komponenten: das anfordernde Gerät (MDM-verwaltetes Gerät oder Netzwerkgerät), den NDES-Server, die Microsoft- Zertifizierungsstelle (CA) und die für SCEP konfigurierte Zertifikatvorlage.

Schritt 1: Geräteanfrageregistrierung

Das Gerät kontaktiert den NDES-HTTPS-Endpunkt über SCEP. Bei Intune-verwalteten Geräten wird dies automatisch durch ein Intune-SCEP-Profil ausgelöst. Das Gerät generiert ein Schlüsselpaar und erstellt eine PKCS#10-Zertifikatsignierungsanforderung (CSR).

Schritt 2: NDES gibt ein Herausforderungspasswort aus

NDES generiert ein Einmalpasswort (OTP) zur Validierung der Anfrage. In Intune-integrierten Umgebungen autorisiert Intune die Anfrage vorab und stellt das OTP über den NDES Connector bereit, sodass kein manuelles Abrufen des OTP erforderlich ist.

Schritt 3: Gerät sendet Zertifikatsanforderung

Das Gerät sendet seine Zertifikatsignierungsanforderung zusammen mit dem Herausforderungspasswort per HTTP-POST-Anfrage an den SCEP-Endpunkt von NDES. NDES validiert die Herausforderung, bevor die Anfrage an die Zertifizierungsstelle weitergeleitet wird.

Schritt 4: NDES übermittelt an die CA

NDES leitet die Anfrage mithilfe der Anmeldeinformationen des NDES-Dienstkontos und der festgelegten Zertifikatvorlage an die Microsoft-Zertifizierungsstelle weiter. Die Zertifizierungsstelle prüft die Anfrage anhand der in der Vorlage festgelegten Richtlinien, Schlüsselverwendung, EKU und Antragstellernamen, bevor sie das Zertifikat ausstellt oder ablehnt.

Schritt 5: Zertifikat wird ausgestellt

Die Zertifizierungsstelle (CA) signiert das Zertifikat und sendet es an NDES zurück. Das Ausstellungsereignis der CA wird in der CA-Datenbank und im Ereignisprotokoll protokolliert. An dieser Stelle sollte die SIEM-Integration das Ausstellungsereignis für Prüfzwecke erfassen.

Schritt 6: Gerät ruft Zertifikat ab

Das Gerät fragt den NDES-Endpunkt ab und ruft das signierte Zertifikat ab. Anschließend installiert es dieses im entsprechenden Zertifikatsspeicher (Gerätespeicher für die Geräteauthentifizierung, Benutzerspeicher für Benutzerzertifikate). Die CLM-Plattform sollte dieses Zertifikat nun im Inventar registrieren, um es nachverfolgen und die Zertifikatserneuerung verwalten zu können.

Häufige NDES-Fehlkonfigurationen, die bei Sicherheitsbewertungen festgestellt wurden

Bei PKI-Sicherheitsbewertungen treten immer wieder mehrere NDES-Fehlkonfigurationen auf. Jede einzelne stellt einen realen Angriffsvektor dar.

1. NDES direkt dem Internet ausgesetzt

NDES-Endpunkte laufen häufig auf IIS und können ungeschützt extern veröffentlicht werden. Dies ermöglicht Angreifern die Zertifikatsregistrierung, das Auflisten von Vorlagen und die Ausnutzung von IIS-Schwachstellen. NDES sollte daher stets durch Anwendungsgateways und rollenbasierte Zugriffsregeln geschützt werden. Veröffentlichen Sie die NDES-URL niemals direkt im Internet; leiten Sie Anfragen immer über einen Reverse-Proxy oder Azure Application Proxy, der die Authentifizierung erzwingt, bevor sie NDES erreichen.

2. Überprivilegierte Servicekonten

NDES verwendet ein Dienstkonto, um Zertifikate von der Zertifizierungsstelle anzufordern. Verfügt dieses Konto über zu hohe Berechtigungen, können Angreifer, die es kompromittieren, eigenständig Zertifikate ausstellen. Dieses Risiko ist besonders gravierend, da Zertifikate zur Authentifizierung und zur lateralen Ausbreitung missbraucht werden können. Das NDES-Dienstkonto sollte lediglich die Berechtigung „Registrieren“ für die entsprechende SCEP-Vorlage, die Mitgliedschaft in der lokalen IIS_IUSRS-Gruppe und die Berechtigung „Anmelden als Dienst“ besitzen. Es darf niemals Mitglied der Gruppen „Domänen-Admins“ oder „Zertifizierungsstellen-Admins“ sein.

3. Schwache Template-Konfiguration

Für SCEP verwendete Vorlagen sind mitunter so konfiguriert, dass sie den Export privater Schlüssel ermöglichen, übermäßig weitreichende Nutzungsrechte gewähren (z. B. Client- und Serverauthentifizierung in derselben Vorlage) und Zertifikate ohne Genehmigung durch den Manager ausstellen. Solche Fehlkonfigurationen können zu Identitätsdiebstahl und Zertifikatsmissbrauch führen. Deaktivieren Sie daher immer den Export privater Schlüssel in SCEP-Vorlagen. Legen Sie die für den jeweiligen Anwendungsfall erforderliche minimale EKU fest. Erwägen Sie, die Genehmigung durch den CA-Manager auch für Vorlagen mit hohen Berechtigungen zu aktivieren, selbst wenn SCEP verwendet wird.

4. Fehlende Überwachung und Protokollierung

Viele Organisationen setzen NDES ein, ohne es jedoch zu überwachen. Ohne ordnungsgemäße Überwachung und Protokollierung bleibt die Ausstellung unberechtigter Zertifikate unbemerkt, der Missbrauch von Registrierungen kann nicht erkannt werden und die Reaktion auf Sicherheitsvorfälle wird erschwert. Integrieren Sie die Ereignisprotokolle der Zertifizierungsstelle (Ereignis-ID 4886 für Zertifikatsanforderungen, Ereignis-ID 4887 für Zertifikatsausstellung) in Ihr SIEM-System. Richten Sie Warnungen für ungewöhnlich hohe Registrierungsspitzen von einer einzelnen Quell-IP-Adresse oder einem einzelnen Gerät ein. Verwenden Sie CBOM Secure , um ein kontinuierliches kryptografisches Inventar aller von NDES ausgestellten Zertifikate zu führen.

Bewährte Sicherheitsverfahren für NDES-Implementierungen

Um NDES in modernen Umgebungen abzusichern, sollten Unternehmen diese bewährten Verfahren befolgen. Weitere Informationen finden Sie im zugehörigen Leitfaden: Bewährte Verfahren für die NDES-Sicherheit.

1. NDES-Server isolieren

NDES sollte niemals direkt auf der Zertifizierungsstelle (CA) installiert werden. Es sollte in einem dedizierten DMZ-Segment hinter einem Reverse-Proxy oder Application Gateway mit eingeschränktem Netzwerkzugriff auf die CA (nur CA-RPC-Ports, blockiert von allen anderen internen Segmenten) bereitgestellt werden. Dadurch wird der Schadensradius im Falle einer Kompromittierung des NDES-Servers begrenzt.

2. Vorlagenberechtigungen einschränken

SCEP-Vorlagen sollten nur die erforderlichen EKUs zulassen, die Formate der Subjektnamen auf „Supplement“ in der Anfrage beschränken (validiert über eine NDES-Herausforderung), den Export des privaten Schlüssels deaktivieren und die Registrierungsberechtigungen nur auf das NDES-Dienstkonto und nicht allgemein auf Domänencomputer festlegen.

3. Überwachung der Zertifikatsausstellung

Protokollieren Sie alle SCEP-Anfragen in den IIS- und CA-Ereignisprotokollen. Überwachen Sie die Vorlagennutzung anhand des Vorlagennamens und des anfragenden Kontos. Benachrichtigen Sie bei ungewöhnlich hohem Registrierungsaufkommen (z. B. mehr als 50 Zertifikatsanfragen pro Stunde von einer einzelnen Quelle). Dies ist besonders wichtig für Vorlagen, die Clientauthentifizierungszertifikate ausstellen, da diese, falls sie in die Hände eines Angreifers gelangen, zur lateralen Ausbreitung missbraucht werden können.

4. IIS-Konfiguration härten

Da NDES auf IIS läuft, deaktivieren Sie nicht benötigte IIS-Module, erzwingen Sie TLS 1.2 oder höher für die NDES-HTTPS-Bindung, wenden Sie HTTPS-Sicherheitsheader (HSTS, X-Content-Type-Options, X-Frame-Options) an und patchen Sie den Server regelmäßig. Die NDES-IIS-Website sollte die einzige Website auf dem Server sein; installieren Sie keine anderen Anwendungen auf demselben Server.

Wo SCEP und NDES ihre Grenzen erkennen

Trotz ihrer weiten Verbreitung wurden SCEP und NDES ursprünglich nicht für die heutigen Cloud-nativen Umgebungen konzipiert. Bei modernen Implementierungen treten häufig verschiedene Herausforderungen auf.

Kontext mit eingeschränkter Sicherheit

SCEP wurde mit Blick auf Einfachheit entwickelt und bietet daher nur eingeschränkte Möglichkeiten zur Identitätsprüfung. Der Mechanismus zur Abfrage des Challenge-Passworts basiert auf einem gemeinsamen Geheimnis und ist kein kryptografisch gesicherter Identitätsnachweis. Um eine starke Geräteauthentifizierung vor der Zertifikatsausstellung zu gewährleisten, sind häufig zusätzliche Kontrollmechanismen erforderlich (z. B. die Vorautorisierung von Intune über den NDES Connector).

Betriebskomplexität

NDES-Implementierungen erfordern dedizierte Server, IIS-Härtung, Planung der Netzwerksicherheit, Konfigurationsmanagement von Vorlagen und Lebenszyklusmanagement von Dienstkonten. In Hybrid- oder Multi-Cloud-Umgebungen mit mehreren NDES-Instanzen führt dies ohne einheitliche CLM-Tools, die Transparenz über alle Instanzen hinweg gewährleisten, zu einem erheblichen Betriebsaufwand.

Skalierungsherausforderungen

Während SCEP für Endgeräte gut geeignet ist, eignet es sich weniger für dynamische Workloads wie Container, Microservices oder kurzlebige Cloud-Instanzen. Diese modernen Workloads erfordern schnellere Zertifikatsausstellungszyklen, stärkere Identitätsprüfungsmechanismen und kurzlebige Zertifikate. ACME bewältigt diese Szenarien effektiver.

Das moderne Framework zur Automatisierung von Zertifikaten: ACME

ACME (Automated Certificate Management Environment) wurde entwickelt, um ein vollautomatisiertes Zertifikatslebenszyklusmanagement mit minimalem menschlichen Eingriff zu ermöglichen. Im Gegensatz zu SCEP ist ACME für moderne Umgebungen konzipiert und unterstützt die automatisierte Zertifikatsausstellung und -erneuerung, API-gesteuerte Workflows, Mechanismen zur Identitätsprüfung sowie kurzlebige Zertifikate gemäß den Zero-Trust-Prinzipien.

ACME ist besonders wertvoll für DevOps-Pipelines, Kubernetes-Cluster, Cloud-native Dienste und die Authentifizierung zwischen Diensten. Unternehmen setzen es zunehmend intern für Workload-Identitäten neben SCEP/NDES für Gerätezertifikate ein.

Vergleich von SCEP, NDES und ACME in der Enterprise-PKI

Jede Technologie dient einem anderen Zweck. Organisationen nutzen sie oft gemeinsam, anstatt sich nur für eine zu entscheiden.

Abmessungen	SCEP / NDES	ACME	Automatische AD-Registrierung
Primärer Anwendungsfall	Gerätezertifikate für Intune-verwaltete Endpunkte, VPN-Clients, IoT-Geräte und Netzwerkgeräte	Server- und Workload-Zertifikate für DevOps-Pipelines, Kubernetes, Cloud-native Dienste	Benutzer- und Computerzertifikate für in eine Domäne eingebundene Windows-Systeme
Geräteanforderung	Erfordert keine Active Directory-Mitgliedschaft; verwendet ein Challenge-Passwort zur Authentifizierung	Benötigt kein Active Directory; verwendet Domänenvalidierung oder API-Token-Authentifizierung.	Erfordert Active Directory-Mitgliedschaft und Gruppenrichtlinien
Lebensdauer des Zertifikats	Unterstützt längerfristige Gerätezertifikate (typischerweise 1 Jahr); Verlängerung über einen neuen SCEP-Antrag	Konzipiert für kurzlebige Zertifikate (Tage bis 90 Tage); automatische Verlängerung im Protokoll integriert.	Unterstützt jeden im Template konfigurierten Gültigkeitszeitraum; Verlängerung über automatische Registrierung per Gruppenrichtlinie.
Infrastruktur erforderlich	NDES-Server (dedizierter Windows Server + IIS), NDES-Dienstkonto, CA-RPC-Zugriff	ACME-kompatibler CA-Endpunkt; kein dedizierter Server über die CA hinaus erforderlich	Domänencontroller, Gruppenrichtlinie, in die Domäne eingebundene Zertifizierungsstelle
Cloud-/Hybrid-Unterstützung	Funktioniert mit Intune über den NDES Connector; erfordert einen lokalen NDES-Server für lokale ADCS.	Nativ für Cloud-Zertifizierungsstellen; funktioniert ohne lokale Infrastruktur	Erfordert eine lokale Active Directory-Umgebung; nicht geeignet für reine Cloud- oder BYOD-Geräte.
PQC-Bereitschaft	Eingeschränkt; abhängig von der Konfiguration des zellulären Automaten und des Vorlagenalgorithmus; keine integrierte Algorithmusaushandlung	Robust; algorithmische Aushandlung im Protokoll integriert; bereit für die Migration nach NIST FIPS 203/204/205	Abhängig von der CA-Vorlagenkonfiguration; erfordert eine Vorlagenaktualisierung für PQC-Algorithmen.
Am besten geeignet,	Intune-Gerätezertifikate, VPN-Zertifikate, WLAN-Zertifikate, IoT-Geräteidentität	Webserver-TLS, Containeridentität, CI/CD-Pipeline-Zertifikate, kurzlebige Dienstzertifikate	Domänengebundene Windows-Benutzer- und Computerzertifikate

Praxisbeispiel: Hybride Unternehmensbereitstellung

Stellen Sie sich ein Unternehmen vor, das Zero Trust einführt und gleichzeitig in die Cloud migriert. Es könnte NDES in Kombination mit Intune einsetzen, um Gerätezertifikate zu verwalten, ACME-basierte Zertifikatsausstellung für Container-Workloads zu nutzen und die automatische ADCS-Registrierung für interne Server durchzuführen. Dieses Hybridmodell ermöglicht es, die Kompatibilität mit bestehenden Systemen zu wahren und gleichzeitig das Zertifikatslebenszyklusmanagement zu modernisieren. Zudem reduziert es die Abhängigkeit von Passwörtern und stärkt die identitätsbasierte Zugriffskontrolle in der gesamten Umgebung.

Wie man die richtige Anmeldemethode auswählt

Wenn Ihr Fokus auf Endgeräten oder Netzwerkgeräten liegt, die nicht in Active Directory eingebunden werden können, ist SCEP mit NDES weiterhin praktikabel und weit verbreitet. Bei modernen Workloads oder stark automatisierten Umgebungen bietet ACME eine bessere Integration und Skalierbarkeit. Wenn Sie in eine Domäne eingebundene Windows-Systeme mit Gruppenrichtlinien verwalten, ist die automatische AD-Registrierung der effizienteste Weg.

Die meisten Unternehmen benötigen alle drei im Zuge ihrer Umstellung auf Cloud-native Sicherheitsmodelle. Eine einheitliche CLM-Plattform wie CertSecure Manager bietet eine zentrale Übersicht über alle drei Ausstellungswege und stellt sicher, dass kein Zertifikat unabhängig vom Ausstellungsweg unentdeckt bleibt.

Die Zukunft der Unternehmenszertifikatsanmeldung

Die zertifikatbasierte Authentifizierung entwickelt sich rasant zum Standardmechanismus für die Absicherung von Unternehmensumgebungen. Mit dem Übergang zu passwortloser Authentifizierung, Durchsetzung der Geräteidentität, Zero-Trust-Zugriffsmodellen und Cloud-nativer Architektur wird die Zertifikatsautomatisierung von einer Nischenfunktion der PKI zu einer zentralen Sicherheitsfunktion.

SCEP und NDES werden voraussichtlich weiterhin für die Geräteregistrierung genutzt, während ACME für Workload-Identitäten und die Automatisierung der Infrastruktur zunehmend eingesetzt wird. Das NIST hat FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) im August 2024 finalisiert. Organisationen, die noch keine PQC-Bereitschaftsplanung begonnen haben, müssen ihre CA-Algorithmusprofile und Zertifikatvorlagen aktualisieren, um Post-Quanten-Algorithmen zu unterstützen. Beginnen Sie mit der PQC-Bereitschaftsbewertung und dem PQC Center of Excellence für eine NIST-konforme Migrationsplanung.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting verfügt über umfassende Erfahrung in der Bereitstellung von End-to-End -PKI-Lösungen für Unternehmen und Behörden. Wir bieten sowohl professionelle Dienstleistungen als auch unsere Automatisierungsplattform ( CertSecure Manager ), um sicherzustellen, dass Ihre PKI sicher, ausfallsicher und zukunftssicher ist.

PKI-Dienste

Umfassende Beratungs-, Design- und Implementierungsdienstleistungen, die Organisationen beim Aufbau, der Modernisierung und der Verwaltung sicherer Public-Key-Infrastrukturen unterstützen.

Projektplanung

Wir analysieren Ihre kryptografische Umgebung, überprüfen PKI-Konfigurationen, Abhängigkeiten und Anforderungen und fassen die Ergebnisse in einem strukturierten, vom Kunden genehmigten Projektplan zusammen.

CP/CPS-Entwicklung

Wir entwickeln Richtlinien für die Zertifizierung (Certificate Policy, CP) und Verfahren für die Zertifizierung (Certificate Practice Statement, CPS) in Übereinstimmung mit RFC 3647. Diese Dokumente werden individuell an die regulatorischen, sicherheitsrelevanten und betrieblichen Anforderungen Ihrer Organisation angepasst.

PKI-Design und -Implementierung

Wir entwickeln und implementieren robuste PKI-Infrastrukturen, einschließlich Offline-Root-CAs, ausstellenden CAs, NDES-Servern und HSM-Integration, je nach Kundenbedarf. Zu den Leistungen gehören PKI-Designdokumente, Aufbauanleitungen, Skripte für die Implementierungsprozesse und Systemkonfigurationen. Nach der Implementierung führen wir umfassende Tests, Validierungen, Feinabstimmungen und Schulungen durch, um Ihr Team optimal zu unterstützen.

Business Continuity und Disaster Recovery

Im Anschluss an die Implementierung entwickeln und setzen wir Strategien für Geschäftskontinuität und Notfallwiederherstellung um, führen Failover-Tests durch und dokumentieren die betrieblichen Arbeitsabläufe für die gesamte PKI- und HSM-Infrastruktur, unterstützt durch einen umfassenden PKI-Betriebsleitfaden.

Laufender Support und Wartung (optional)

Nach der Implementierung bieten wir ein abonnementbasiertes Jahres-Supportpaket mit umfassender Abdeckung für PKI-, CLM- und HSM-Komponenten. Dieses beinhaltet Incident Response, Fehlerbehebung, Systemoptimierung, Zertifikatslebenszyklusmanagement, CP/CPS-Updates, Schlüsselarchivierung, HSM-Firmware-Upgrades, Audit-Protokollierung und Patch-Management.

Dieser Ansatz stellt sicher, dass Ihre PKI-Infrastruktur nicht nur sicher und konform, sondern auch skalierbar, belastbar und vollständig auf Ihre langfristigen betrieblichen und regulatorischen Ziele abgestimmt ist.

CertSecure Manager

CertSecure Manager von Encryption Consulting ist eine Lösung für das Zertifikatslebenszyklusmanagement, die den gesamten Lebenszyklus vereinfacht und automatisiert, sodass Sie sich auf die Sicherheit anstatt auf Verlängerungen konzentrieren können.

• Automatisierung für kurzlebige Zertifikate: Da ACME- und 90-Tage-/47-Tage-TLS-Zertifikate zum Standard geworden sind, ist die manuelle Erneuerung keine praktikable Option mehr. CertSecure Manager automatisiert Registrierung, Erneuerung und Bereitstellung, um sicherzustellen, dass Zertifikate niemals unbemerkt ablaufen.
• Nahtlose DevOps- und Cloud-Integration: Zertifikate können direkt auf Webservern und Cloud-Instanzen bereitgestellt werden und lassen sich in moderne Protokollierungstools wie Datadog, Splunk, ITSM-Tools wie ServiceNow und DevOps-Tools wie Terraform und Ansible integrieren.
• Multi-CA-Unterstützung: Viele Organisationen nutzen mehrere Zertifizierungsstellen (interne Microsoft-Zertifizierungsstelle, öffentliche Zertifizierungsstellen wie DigiCert und GlobalSign usw.). CertSecure Manager integriert diese Quellen und bietet eine zentrale Oberfläche für die Ausstellung und das Lebenszyklusmanagement von Zertifikaten über SCEP/NDES- und ACME-Registrierungspfade hinweg.
• Einheitliche Ausstellungs- und Verlängerungsrichtlinien: CertSecure Manager sorgt dafür, dass die Schlüssellängen, Algorithmen und Erneuerungsregeln Ihrer Organisation für alle Zertifikate einheitlich gelten und gewährleistet so, dass jedes Zertifikat jederzeit Ihren Sicherheitsstandards entspricht.
• Proaktive Überwachung und Erneuerungstests: Die kontinuierliche Überwachung in Kombination mit simulierten Erneuerungs- und Ablaufprüfungen stellt sicher, dass Sie Risiken erkennen, bevor Zertifikate Auswirkungen auf Produktionssysteme haben.
• Zentralisierte Transparenz und Compliance: Ein übersichtliches Dashboard zeigt alle Zertifikate, Schlüssellängen, starken und schwachen Algorithmen sowie deren Ablaufdaten an. Prüfprotokolle und die Durchsetzung von Richtlinien vereinfachen die Einhaltung der Vorschriften. PCI DSS, HIPAAund andere Frameworks.

Sie fragen sich, wie Sie mit der Absicherung Ihrer PKI beginnen können? Encryption Consulting unterstützt Sie mit seinen PKI-Support-Services . Verlassen Sie sich auf uns als Ihren vertrauenswürdigen Partner – wir begleiten Sie Schritt für Schritt, klar, kompetent und mit fundierter Praxiserfahrung.

Fazit

Enterprise-PKI entwickelt sich von einem Backend-Sicherheitstool zu einer zentralen Identitätsinfrastruktur. Das Verständnis des Zusammenspiels von SCEP, NDES und ACME ermöglicht es Unternehmen, skalierbare Zertifikatsverwaltungssysteme aufzubauen, die sowohl Legacy-Umgebungen als auch moderne Cloud-Workloads unterstützen. Durch die Kombination traditioneller PKI-Grundlagen mit modernen Automatisierungsframeworks können Unternehmen eine stärkere identitätsbasierte Sicherheit erreichen, ohne die betriebliche Effizienz zu beeinträchtigen.

NDES ist weiterhin unerlässlich für hybride Intune-Bereitstellungen und die Zertifikatsregistrierung für Geräte außerhalb der Domäne. Die Bereitstellung und Absicherung muss jedoch mit der gleichen Sorgfalt erfolgen wie bei der Zertifizierungsstelle selbst. Jeder falsch konfigurierte NDES-Server ist als potenzielles Sicherheitsrisiko für die Zertifikatsausstellung zu betrachten. Investieren Sie in CLM-Tools, um die vollständige Transparenz über die von NDES ausgestellten Zertifikate zu gewährleisten, und beginnen Sie jetzt mit der Planung der PQC-Bereitschaft, damit Algorithmusübergänge keine Notfall-Neukonfigurationen der Zertifizierungsstelle erfordern, wenn regulatorische Fristen anstehen.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus „NDES und SCEP erklärt: Das Rückgrat der automatisierten Zertifikatsregistrierung“?

SCEP ist nach wie vor das De-facto-Protokoll für die automatisierte Gerätezertifikatsregistrierung in Microsoft-PKI-Umgebungen, und NDES bildet die notwendige Schnittstelle zwischen SCEP-fähigen Geräten und ADCS. Ohne NDES können Intune, MDM-Plattformen und Geräte außerhalb der Domäne keine Zertifikate von einer lokalen Zertifizierungsstelle beziehen. Fehlkonfigurierte NDES-Server zählen zu den am häufigsten ausgenutzten PKI-Schwachstellen und sollten mit der gleichen Sorgfalt behandelt werden wie die Zertifizierungsstelle selbst.

Warum sind NDES und SCEP für PKI-Teams in Unternehmen wichtig?

Enterprise-PKI-Teams sind für die Zertifikatsinfrastruktur verantwortlich, auf der Intune, MDM, VPN, WLAN und Zero-Trust-Zugriffssysteme basieren. Über NDES beziehen diese Systeme Zertifikate von ADCS für Geräte außerhalb der Domäne. Laut der DigiCert Trust Pulse Survey (2. Juli 2025) erlebte fast die Hälfte der Unternehmen im vergangenen Jahr Ausfallzeiten aufgrund von Zertifikatsproblemen. Ein falsch konfigurierter oder nicht verfügbarer NDES-Server kann die Geräteauthentifizierung im gesamten Unternehmen gleichzeitig unterbrechen.

Welche Risiken steigen, wenn NDES und SCEP nicht ordnungsgemäß gesichert sind?

Zu den Risiken gehören: Ein mit dem Internet verbundener NDES-Endpunkt ermöglicht es Angreifern, Zertifikatvorlagen aufzulisten und eine unbefugte Registrierung zu versuchen; ein übermäßig privilegiertes Dienstkonto ermöglicht es Angreifern, sich als dieses auszugeben und unabhängig Zertifikate auszustellen; eine schwache Vorlagenkonfiguration mit exportierbaren privaten Schlüsseln schafft Vektoren für Identitätskompromittierung; und fehlende Überwachung bedeutet, dass die Ausstellung unautorisierter Zertifikate unentdeckt bleibt, bis ein Vorfall eintritt.

Welche Teams sollten für die Bereitstellung und Sicherheit von NDES und SCEP verantwortlich sein?

PKI-Administratoren sind für die Bereitstellung des NDES-Servers, die Konfiguration der Zertifikatvorlagen und die CA-Richtlinien verantwortlich. Sicherheitsarchitekten verantworten das Design der Netzwerkisolation und die Härtungsstandards für IIS. Plattform- und Endpunktteams sind für die MDM/Intune-Integration und die Geräteregistrierungsprofile zuständig. Compliance-Teams verantworten die Anforderungen an die Audit-Protokolle und die Überwachungsnachweise. CISOs sind für den Eintrag im Risikoregister für NDES als potenziell hochriskante Angriffsfläche verantwortlich, da NDES eine wichtige Rolle bei der Zertifikatsausstellung für die Authentifizierung spielt.

Wie hängen NDES und SCEP mit dem Zertifikatslebenszyklusmanagement zusammen?

NDES und SCEP bearbeiten die Erstregistrierung und Verlängerungsanfragen von Geräten für Zertifikate. Das Zertifikatslebenszyklusmanagement (CLM) bildet die übergeordnete operative Ebene, die alle Zertifikate in der Umgebung verfolgt, überwacht und verwaltet. CertSecure Manager integriert sich in die Registrierungsprozesse von SCEP/NDES und bietet eine einheitliche Übersicht über ADCS-ausgestellte Zertifikate, öffentliche CA-Zertifikate und Cloud-Zertifikate in einem einzigen Dashboard mit automatisierten Ablaufbenachrichtigungen und Verlängerungs-Workflows.

Wie sollten Organisationen den Erfolg nach der Einführung von NDES messen?

Zu den wichtigsten Kennzahlen gehören: Prozentsatz der Zielgeräte, die erfolgreich über SCEP/NDES registriert wurden (Ziel: 100 % der MDM-verwalteten Geräte); Anzahl der fehlgeschlagenen SCEP-Registrierungsversuche pro Woche (Ziel: Tendenz gegen Null nach anfänglicher Stabilisierung); Authentifizierungsfehler aufgrund von NDES-ausgestellten Zertifikaten im Zusammenhang mit deren Ablauf pro Quartal (Ziel: Null); Zeit bis zur Erkennung eines über NDES ausgestellten betrügerischen oder nicht autorisierten Zertifikats (Ziel: am selben Tag per SIEM-Warnung); und Verfügbarkeit des NDES-Servers (Ziel: mindestens 99.9 %).

Was sollte bei einer NDES-Implementierung regelmäßig geprüft oder überwacht werden?

Kontinuierliche Überwachung: SCEP-Registrierungsanfragen und Fehlerraten; über NDES in der CA-Datenbank ausgestellte Zertifikate; Zustand des NDES-IIS-Anwendungspools; Netzwerkzugriffe auf den NDES-Endpunkt von unerwarteten Quell-IP-Adressen. Vierteljährliche Prüfung: NDES-Dienstkontoberechtigungen gemäß dem Prinzip der minimalen Berechtigungen; Zertifikatvorlagenkonfiguration für SCEP; IIS-Konfiguration zur Durchsetzung der TLS-Version; und Patch-Level des NDES-Server-Betriebssystems.

Wie wirkt sich NDES auf Cloud-, Hybrid- oder Multi-CA-Umgebungen aus?

In hybriden Umgebungen, in denen Intune sowohl Cloud-native als auch lokale Geräte verwaltet, ist NDES die notwendige Brücke für die Zertifikatsausstellung von lokalen ADCS-Systemen an Cloud-verwaltete Geräte. In Umgebungen mit mehreren Zertifizierungsstellen (CAs) betreiben Unternehmen möglicherweise mehrere NDES-Instanzen. Ohne CLM-Tools, die eine einheitliche Transparenz gewährleisten, entstehen durch die von verschiedenen NDES-Instanzen und CAs ausgestellten Zertifikate Lücken im Zertifikatsbestand. CBOM Secure automatisiert die kryptografische Erkennung in diesen hybriden Umgebungen und gewährleistet so einen vollständigen und revisionssicheren Zertifikatsbestand.

Welche Voraussetzungen müssen vor der Bereitstellung von NDES erfüllt sein?

Voraussetzungen sind: eine funktionierende ADCS-Umgebung mit mindestens einer ausstellenden Zertifizierungsstelle; Windows Server 2016 oder höher für die NDES-Rolle; ein dediziertes Dienstkonto mit CA-Registrierungsrechten und IIS-Zugriff (kein Domänenadministrator); eine für die SCEP-Registrierung konfigurierte Zertifikatvorlage mit korrekter Schlüsselverwendung (digitale Signatur), EKU und ohne exportierbare private Schlüssel; IIS auf dem NDES-Server; und ein gültiges SSL-Zertifikat für den NDES-HTTPS-Endpunkt. NDES darf nicht auf dem CA-Server selbst installiert sein.

Auf welche häufigen Fehler sollten Administratoren bei der Bereitstellung von NDES achten?

Häufige Fehler sind: HTTP 403-Fehler auf der NDES-URL aufgrund von Problemen mit IIS-Berechtigungen oder der Identität des Anwendungspools; Fehler beim Abrufen des Challenge-Passworts, weil dem NDES-Dienstkonto die Berechtigungen zur CA-Registrierung fehlen; Ablehnungen von Zertifikatsanforderungen aufgrund von Fehlkonfigurationen der Vorlage oder fehlender EKU; Abstürze des NDES-Anwendungspools aufgrund von Speicher- oder IIS-Modulproblemen; und Geräte, die dem NDES-SSL-Zertifikat nicht vertrauen können, weil sich die ausstellende CA nicht im Geräte-Truststore befindet.