IoT-Geräte automatisch onboarden – So hilft Azure DPS mit Zertifikaten

Wenn Onboarding zur Fleißarbeit wird

Du kennst das: Ein neues IoT-Gerät soll an den Start – doch bevor es „Hallo Cloud“ sagen kann, brauchst du Konfiguration, Keys, Ziel-Hub und Nerven wie Drahtseile. Bei fünf Geräten kein Problem. Bei 5.000 wird’s zur Geduldsprobe.

Hier kommt Azure DPS ins Spiel.
Der Device Provisioning Service nimmt dir diese Fleißarbeit ab: automatisiert, sicher und skalierbar. Statt manuellem Aufwand sorgt DPS dafür, dass sich jedes neue Gerät selbst registriert – ganz ohne Zettelwirtschaft und Fehlkonfigurationen.

Doch bevor wir tiefer einsteigen, lass uns erst klären, was DPS eigentlich genau macht.

Azure DPS erklärt: So funktioniert dein Geräte-Autopilot

Azure DPS ist der Autopilot für IoT-Geräte. Es sorgt dafür, dass jedes neue Gerät beim ersten Einschalten automatisch dem richtigen IoT Hub zugeordnet wird – ohne Vorwissen, manuelle Eingriffe oder Spezialkonfigurationen.

• Ohne DPS: Jedes Gerät muss manuell vorkonfiguriert werden – das ist fehleranfällig, aufwendig und kaum skalierbar.
• Mit DPS: Geräte verbinden sich nur mit dem zentralen Service. DPS übernimmt automatisch die sichere Registrierung und Hub-Zuweisung.

Kurz gesagt: DPS ist dein digitaler Empfangsroboter – er begrüßt jedes neue Gerät schickt es direkt an den richtigen Platz im Netzwerk.

Jetzt stellt sich aber die Frage: Wie weisen sich die Geräte eigentlich aus? Genau hier kommen Zertifikate ins Spiel.

Warum X.509-Zertifikate dein IoT sicherer und smarter machen

Warum eigentlich Zertifikate? Wären einfache Zugangsschlüssel nicht leichter?

Nicht wirklich – Keys sind wie Haustürschlüssel unter der Fußmatte: schnell verteilt, leicht zu kopieren und unsicher. Zertifikate dagegen sind der digitale Ausweis deiner Geräte – schwer zu fälschen und mit klaren Regeln zur Validierung und Verwaltung.

Die wichtigsten Vorteile auf einen Blick:

7 Schritte zum Zertifikat: So kommt dein Gerät sicher in die Cloud

1. Fabrik: Das Gerät wird produziert und erhält ein „Birth Certificate“ – eine Art Geburtsurkunde.
2. Installation: Dieses Zertifikat wird fest im Gerät gespeichert – bereit für den ersten Einsatz.
3. Online-Start: Das Gerät geht erstmals online und stellt über den EST-Standard eine Zertifikatsanfrage (CSR).
4. PKI-Ausstellung: Die Zertifizierungsstelle (PKI) prüft die Anfrage und stellt ein gültiges Geräte-Zertifikat aus.
5. Rückgabe: Das neue Device Certificate wird an das Gerät zurückgegeben und dort sicher gespeichert.
6. Anmeldung: Das Gerät nutzt dieses Zertifikat, um sich sicher beim Azure DPS zu authentifizieren.
7. Zuweisung: DPS prüft das Zertifikat und weist das Gerät automatisch dem passenden IoT Hub zu.

Symmetric Keys, TPM & Co: Diese Authentifizierungsmethoden gibt’s noch

Neben X.509-Zertifikaten bietet Azure IoT weitere Möglichkeiten zur Geräteauthentifizierung – jede mit eigenen Vorteilen und Grenzen:

• Symmetric Keys

Stell dir vor, jedes Gerät bekommt einfach ein Passwort. Schnell eingerichtet, aber hochriskant bei Diebstahl oder Kopie – dann ist Tür und Tor offen. Ideal für Tests oder Prototypen, ungeeignet für große, produktive Flotten.

• TPM (Trusted Platform Module)

Ein Hardware-Chip im Gerät speichert Schlüssel extrem sicher – praktisch nicht auslesbar. Höchste Sicherheit, aber nur einsetzbar, wenn die Hardware TPM unterstützt.

• X.509-Zertifikate

Der „amtliche Ausweis“ für deine Geräte. Einmal eingerichtet, ermöglichen sie skalierbares, automatisiertes und sicheres Onboarding. Standardisiert, flexibel und zukunftssicher – dafür etwas aufwendiger im Setup.

Kurzgefasst:

• Keys = einfach, aber unsicher
• TPM = sicher, aber hardwareabhängig
• Zertifikate = optimal für große Flotten und langfristige Lösungen

Und damit diese Zertifikate in der Praxis wirken können, brauchen wir im DPS ein cleveres Setup: die sogenannten Enrollment Groups.

So richtest du eine Enrollment Group mit Zertifikaten richtig ein

Statt jedes Gerät einzeln zu registrieren, kannst du in Azure DPS effizient arbeiten – mit zwei Arten von Enrollments:

1. Individual Enrollment → Ideal für Tests oder Einzelgeräte.
2. Enrollment Group → Perfekt für Flotten, die auf ein gemeinsames Zertifikat vertrauen.

So funktioniert die Enrollment Group:

• Du lädst ein Root- oder Intermediate-Zertifikat in DPS hoch.
• Geräte mit passenden Zertifikaten verbinden sich beim Start mit dem DPS.
• DPS prüft das Zertifikat und weist das Gerät automatisch dem passenden IoT Hub zu.

Das ist wie ein VIP-Armband auf einem Festival: Wer das richtige Zertifikat trägt, kommt automatisch rein – der Security (DPS) checkt nur kurz, ob es echt ist.

Aber was, wen du Geräte nach Region, Kunde oder Produktionscharge verteilen willst?

Dann hilft ein smarter Trick:

Informationen wie Seriennummern kannst du direkt im Zertifikat ablegen unterbringen – in einem Subject oder einer Extension.

Mit Custom Allocation Policies kannst du DPS so erweitern, dass es Geräte regelbasiert zuweist, z.B. „Geräte mit Seriennummer 1000–1999 → Hub A, alle anderen → Hub B.“

Das Ergebnis: Zertifikate sichern nicht nur ab – sie ermöglichen auch eine automatische, intelligente Verteilung deiner Geräte in verschiedenen IoT Hubs.

Damit Zertifikate nicht nur für die Authentifizierung, sondern auch für die automatische Verteilung genutzt werden können, lassen sich zusätzliche Informationen direkt im Zertifikat-Subject ablegen – zum Beispiel die Gerätefamilie oder die Seriennummer.

Ein typisches Feld dafür ist CN (Common Name). Dieses wird oft für Namen oder Seriennummern genutzt und eignet sich hervorragend, um Geräte automatisch nach Familien oder Seriennummernbereichen verschiedenen IoT Hubs zuzuordnen.

Damit du siehst, wie das in der Praxis aussehen kann, hier ein vereinfachtes Beispiel in C#:

Code Beispiel für Allocations-Regeln

// Azure Function - DPS Custom Allocation (simplified)

// Assume we already extracted the certificate subject, e.g.:
// CN=SensorFamilyA-12345, O=MyCompany, C=DE
string subject = "<subject from x509CertificateInfo>";
string chosenHub;

// --- Extract family and serial number from CN ---
string cn = subject.Split(',')
                   .FirstOrDefault(p => p.Trim().StartsWith("CN="))
                   ?.Substring(3).Trim(); 

// Example CN looks like: "SensorFamilyA-12345"
string family = cn?.Split('-')[0];   // "SensorFamilyA"
string serial = cn?.Split('-')[1];   // "12345"

// --- Allocation Rule 1: Route by device family (from CN) ---
if (family == "SensorFamilyA")
    chosenHub = "iothub-a.azure-devices.net";
else if (family == "SensorFamilyB")
    chosenHub = "iothub-b.azure-devices.net";

// --- Allocation Rule 2: Route by serial number range (override or complement) ---
// Example: 1000–1999 -> Hub A, 2000–2999 -> Hub B, else -> Hub C
if (int.TryParse(serial, out var sn))
{
    if (sn >= 1000 && sn <= 1999)       chosenHub = "iothub-a.azure-devices.net";
    else if (sn >= 2000 && sn <= 2999)  chosenHub = "iothub-b.azure-devices.net";
    else                                chosenHub = "iothub-c.azure-devices.net";
}


// ... return chosenHub back to DPS in the response ...

So lassen sich Geräte ganz ohne manuelle Eingriffe regelbasiert auf die passenden IoT Hubs verteilen.

Für viele Szenarien reicht es jedoch schon, jede Gerätefamilie mit einem eigenen Zertifikat und damit einer eigenen Enrollment Group auszustatten. Erst wenn du innerhalb einer Familie feiner unterscheiden willst – etwa nach Seriennummer oder Einsatzumgebung – lohnt sich der Einsatz einer Custom Allocation Policy per Azure Function.

Doch wie sieht der komplette Weg eines Geräts von der Fabrik bis in die Cloud eigentlich aus?

Geräte automatisch bereitstellen: Der Weg vom Werk zum IoT Hub

Der Weg eines IoT-Geräts in die Cloud läuft nach einem klar definierten Ablauf – Schritt für Schritt:

1. Fabrik: Das Gerät bekommt ein erstes „Geburtszertifikat“.
2. Auslieferung: Es geht an den Kunden – noch ohne zu wissen, welchen IoT Hub es später nutzen wird.
3. Erststart im Feld: Beim Einschalten meldet sich das Gerät verbindet beim DPS (global.azure-devices-provisioning.net).
4. Provisionierung: DPS prüft das Zertifikat und weist Gerät automatisch dem passenden IoT Hub zu.
5. Betrieb: Ab diesem Moment kommuniziert das Gerät nur noch mit „seinem“ Hub – sicher, zuverlässig und ohne manuelle Eingriffe.

Im Grunde wie ein Check-in am Flughafen: Boarding-Pass zeigen, Gate zugewiesen bekommen – und los geht’s.

Damit das Ganze zuverlässig und sicher funktioniert, braucht es allerdings ein paar Regeln und Best Practices.

So bleibt dein IoT-Setup sicher: Best Practices & Schutzmaßnahmen

So komfortabel automatisiertes Geräte-Onboarding mit DPS auch ist – Sicherheit bleibt der Dreh- und Angelpunkt. Damit dein Setup zuverlässig und geschützt läuft, solltest du ein paar Grundregeln beachten:

• Zertifikatskette schützen: Root- und Intermediate Zertifikate immer sicher speichern und verwalten.
• Rotation einplanen: Zertifikate rechtzeitig erneuern, bevor sie ablaufen.
• Revocation nutzen: Kompromittierte Geräte-Zertifikate sofort sperren, um Missbrauch zu verhindern.
• Hardware-Schutz: Private Keys gehören ausschließlich in sichere Hardware wie HSM oder TPM.
• Monitoring aktiv halten: Enrollment-Prozesse regelmäßig testen und Logs im Blick behalten.

Quellen:

• X.509 certificate attestation mit Azure DPS (Microsoft)
• Security practices for Azure IoT device manufacturers (Microsoft)
• Tutorial: Provision X.509 devices using Enrollment Groups (Microsoft)
• Roll X.509 certificates in DPS (Microsoft)
• EST – Enrollment over Secure Transport (DigiCert)
• Automatic IoT Edge Certificate Management with GlobalSign EST (Microsoft / GlobalSign)