KMS-Ausschreibung: Vorlage und Anforderungskatalog (2026)

Diese KMS-Ausschreibungsvorlage liefert Ihnen einen herstellerneutralen Anforderungskatalog für die Ausschreibung eines Key-Management-Systems (KMS): neun Anforderungsgruppen, rund 90 Anforderungen mit Priorität und Nachweis, ein gewichtetes Bewertungsmodell, Anbieterfragen, Warnsignale, einen Proof-of-Concept-Plan und Ausstiegsklauseln. Sie deckt HSM-gestützte, Cloud-, externe (HYOK, DKE, XKS, EKM, BYOK) und MPC-basierte Schlüsselverwaltung ab. Alle Tabellen lassen sich in eine Tabellenkalkulation kopieren.

---

Inhaltsverzeichnis

1. Für wen diese Vorlage gedacht ist und wie Sie sie nutzen
2. Bevor Sie die Ausschreibung schreiben
3. Der KMS-Anforderungskatalog
4. Gewichtetes Bewertungsmodell
5. Fragen an die Anbieter
6. Warnsignale in Anbieterantworten
7. Proof-of-Concept-Plan
8. Vertrags- und Ausstiegsklauseln
9. Einleitungstext zum Kopieren
10. FAQ
11. Quellen

---

Für wen diese Vorlage gedacht ist und wie Sie sie nutzen

Der Anforderungskatalog richtet sich an Sicherheitsarchitekten, CISOs, Einkauf und Compliance, die eine Ausschreibung, eine Informationsanfrage (RFI) oder ein Pflichtenheft für ein KMS erstellen müssen. Er setzt voraus, dass Sie bereits wissen, warum Sie Schlüssel zentral verwalten wollen; andernfalls beginnen Sie mit unserem Leitfaden zur unternehmensweiten Schlüsselverwaltung und nutzen die Kaufberatung zur besten KMS-Lösung, um den Markt zu verstehen.

So gehen Sie vor:

1. Streichen Sie Gruppen ausserhalb Ihres Umfangs und passen Sie die Prioritäten an Ihre Risikobewertung an.
2. Behalten Sie die Anforderungs-IDs bei, damit Antworten und Bewertungen nachvollziehbar bleiben.
3. Prioritäten: Muss (Ausschlusskriterium), Soll (bewertet, eine Lücke ist vertretbar) und Erweitert (differenzierend, als Bonus bewertet, nie ausschliessend).
4. Lassen Sie jede Zeile beantworten mit: Erfüllt, Teilweise erfüllt oder Nicht erfüllt, plus dem Nachweis aus der letzten Spalte (Dokumentationslink, Zertifikatsnummer oder Demonstration).

Die Anforderungen sind so formuliert, dass seriöse Produkte mehrerer Kategorien (HSM-zentrierte Plattformen, Multi-Cloud-KMS, MPC-basierte KMS, Key Management as a Service) sie erfüllen und belegen können. Punkte, die nur manche Architekturen bieten, sind als Erweitert gekennzeichnet.

---

Bevor Sie die Ausschreibung schreiben

Investieren Sie eine Woche in diese Fragen. Die meisten gescheiterten KMS-Projekte scheitern hier, nicht bei der Anbieterwahl.

Umfang.

• Welche Schlüssel sind betroffen: Datenverschlüsselungsschlüssel, Schlüsselverschlüsselungsschlüssel, Signaturschlüssel, TLS- und Code-Signing-Schlüssel, Master-Schlüssel von Secrets-Plattformen?
• Welche Plattformen müssen das KMS aufrufen: Microsoft 365, AWS, Azure, Google Cloud, Salesforce, Snowflake, Oracle, SQL Server, VMware, Kubernetes, Eigenentwicklungen?
• Verlangt eine Plattform einen externen Schlüsselspeicher (XKS), Double Key Encryption (DKE), kundenverwaltete Schlüssel (BYOK) oder Hold Your Own Key (HYOK)?

Bestandsaufnahme.

• Wo liegen Ihre Schlüssel heute (Cloud-KMS, HSMs, SaaS-Konsolen, Vaults, Skripte)? Wie viele, welcher Art, mit welcher Rotationspraxis?
• Welche Schlüsselspeicher sind zu migrieren, welche abzulösen?

Beteiligte.

• Sicherheitsarchitektur, Infrastruktur und Cloud, Anwendungsverantwortliche, Compliance und Recht, Einkauf sowie das Betriebsteam. Benennen Sie eine verantwortliche Person für den Ausstiegsplan.

Rahmenbedingungen und Treiber.

• Regulatorische Treiber, zum Beispiel DORA (Verordnung (EU) 2022/2554) für Finanzunternehmen in der EU, NIS2 (Richtlinie (EU) 2022/2555), DSGVO Artikel 32, das Schweizer DSG oder branchenspezifische Erwartungen wie die der FINMA. Halten Sie fest, welche Vorschrift welche Kontrolle verlangt.
• Datenresidenz und Rechtsordnung: Wer kann den Anbieter rechtlich zur Herausgabe zwingen, und wo liegen Schlüssel und Protokolle?
• Zertifizierungsvorgaben: FIPS-140-3-Level, Common Criteria, nationale Zulassungen.

Entscheidungskriterien. Legen Sie die Gewichte des Bewertungsmodells unten fest, bevor Sie eine Antwort sehen. Gewichte nach den Demos zu ändern, ist das Einfallstor für Voreingenommenheit.

---

Der KMS-Anforderungskatalog

Legende: M = Muss, S = Soll, E = Erweitert (differenzierend). Die Spalte Nachweis nennt, was der Käufer in der Antwort anfordern sollte.

1. Schlüssel-Lebenszyklus-Management

2. Schlüsselverwahrung und -schutz (HSM, KMS, MPC)

3. Integrationen (Cloud-EKM und -XKS, Microsoft 365, Datenbanken, SaaS)

4. Kryptografie (Algorithmen, PQC)

5. Zugriffskontrolle und Quorum

6. Audit und Monitoring

7. Verfügbarkeit und Disaster Recovery

8. Bereitstellung und Souveränität

9. Anbieter und Support

---

Gewichtetes Bewertungsmodell

Bewerten Sie jede Gruppe von 0 bis 5, multiplizieren Sie mit dem Gewicht und summieren Sie. Legen Sie die Gewichte fest, bevor Sie eine Antwort lesen. Jedes nicht erfüllte Muss schliesst aus, unabhängig von der Gesamtsumme.

Bewertungsskala pro Anforderung oder Gruppe

Beispielgewichte (an Ihr Risikoprofil anpassen; die Summe muss 100 ergeben)

Rechenbeispiel (erfundene Zahlen, nur zur Veranschaulichung). Drei generische Anbieter A, B und C mit Gruppenbewertungen von 0 bis 5.

Rechnung für A: 12x4 + 18x5 + 18x3 + 8x3 + 10x4 + 9x3 + 10x4 + 8x4 + 7x3 = 48 + 90 + 54 + 24 + 40 + 27 + 40 + 32 + 21 = 376. Lassen Sie Ihre Tabellenkalkulation das mit SUMMENPRODUKT aus Gewichten und Punkten rechnen. Ein knappes Ergebnis (hier liegen A und C wenige Punkte auseinander) ist ein Anlass, den PoC zu verlängern oder die erweiterten Punkte neu zu prüfen, nicht, allein nach dem Preis zu entscheiden.

---

Fragen an die Anbieter

Nehmen Sie diese als Freitextfragen in die Ausschreibung auf; sie fördern zutage, was ein Häkchen nicht zeigt.

1. Wer bei Ihnen oder bei uns kann technisch einen vollständigen Schlüssel nutzen oder exportieren? Zeigen Sie uns die Kontrolle, die das verhindert.
2. Wo wird Schlüsselmaterial erzeugt, gespeichert und gesichert, und in welcher Form in jedem Schritt?
3. Welche der Muss-Anforderungen erfüllt ein Drittprodukt, welche Ihr eigenes?
4. Welche KMIP-Operationen und PKCS#11-Funktionen sind nicht implementiert?
5. Welche Integrationen Ihrer Liste sind allgemein verfügbar, welche Beta oder geplant? Nennen Sie jeweils den Dokumentationslink.
6. Was geschieht mit bestehenden Dokumenten, Datenbanken oder Objekten bei einer Schlüsselrotation, je integrierter Plattform?
7. Was passiert auf jeder integrierten Plattform, wenn das KMS 5 Minuten, 1 Stunde und 24 Stunden nicht verfügbar ist?
8. Wie belegen Sie einem Prüfer die Integrität der Audit-Logs?
9. Welche Monitoring-Protokolle unterstützen Sie nativ (SNMP, Prometheus, Syslog), welche nur mit Zusatzmodul?
10. Wie werden Administrator-Freigaben (Quorum) für Löschen, Export und Wiederherstellung durchgesetzt, und kann der Anbieter sie umgehen?
11. Wie ist Ihr Support ausserhalb der Geschäftszeiten organisiert, und welche vertragliche Reaktionszeit gilt bei kritischen Störungen?
12. Welche Modulzertifikate (CMVP-Nummern) gelten für welche Versionen, und wie ist der Validierungsstatus der exakt gelieferten Version?
13. Wie unterstützen Sie Algorithmenwechsel, einschliesslich ML-KEM und ML-DSA, und wie lautet Ihre datierte Roadmap?
14. Wie sieht der Ausstieg aus: Welche Schlüssel sind exportierbar, in welchen Formaten, unter welchen Freigaben, und welche nicht?
15. Welche Betriebssysteme und Laufzeitumgebungen werden unterstützt, und wann erreicht jede ihr Support-Ende?
16. Welche Rechtsordnungen können Sie oder Ihre Unterauftragnehmer zur Herausgabe von Kundendaten oder Schlüsselmaterial zwingen?
17. Wer sind Ihre Unterauftragsverarbeiter, und wo arbeiten sie?
18. Was kostet die Lösung für unsere Mengen über fünf Jahre, inklusive Support, HSM oder Hardware, Integrationen und Wachstum?
19. Beschreiben Sie den letzten Sicherheitsvorfall Ihres Produkts, den Zeitplan der Offenlegung und die Korrektur.
20. Nennen Sie zwei Referenzen mit vergleichbarer Umgebung und stimmen Sie einem Gespräch zu.

---

Warnsignale in Anbieterantworten

• «Wir unterstützen alle Clouds» ohne Leitfaden pro Plattform oder Referenzkunden.
• Verwahrungsantworten, die der Frage ausweichen. Fragen Sie, wer einen vollständigen Schlüssel nutzen kann, und erhalten eine Funktionsliste, gehen Sie davon aus, dass der Anbieter es kann.
• Zertifikate für das Unternehmen statt für das Modul. Die FIPS-140-Validierung gilt für ein bestimmtes Modul und eine Version. Prüfen Sie die Nummer auf der CMVP-Website, und beachten Sie, dass FIPS-140-2-Zertifikate nach dem 21. September 2026 in die Liste «Historical» wechseln.
• Rotation, die ein Neu-Labeling- oder Neuverschlüsselungsprojekt erfordert, ohne dass dies gesagt wird.
• Standardmässig offene Autorisierung, etwa eine leere Erlaubnisliste, die den gesamten Mandanten zulässt.
• Protokolle nur als lokale Dateien oder vom Administrator änderbar.
• Laufzeitumgebungen oder Betriebssysteme ohne Support in der Liste der unterstützten Plattformen.
• Kein Ausstieg: Schlüssel sind in keinem Standardformat exportierbar, und der Anbieter beschreibt keinen Migrationsprozess.
• Roadmap als Fähigkeit verkauft, besonders bei Post-Quanten-Algorithmen.
• Preise, die mit Schlüsseln, Operationen oder Integrationen unvorhersehbar wachsen, ohne Rechenbeispiel.
• Verweigerter Proof of Concept auf Ihrer Last oder ein PoC, der nur eine vom Anbieter geführte Vorführung ist.

---

Proof-of-Concept-Plan

Führen Sie den PoC zwei bis vier Wochen auf Ihren eigenen Mandanten und Workloads durch, mit vorab vereinbarten Erfolgskriterien. Jeder Test ist bestanden oder nicht bestanden.

Erfassen Sie neben dem Ergebnis auch den Aufwand: aufgewendete Stunden, manuelle Schritte und eröffnete Support-Tickets.

---

Vertrags- und Ausstiegsklauseln

Verhandeln Sie diese vor der Unterschrift, solange Sie noch Verhandlungsmacht haben.

• Schlüsseleigentum. Schlüssel und Metadaten gehören Ihnen; der Anbieter hält keine nutzbare Kopie, sofern Vertrag und Architektur nichts anderes festlegen.
• Export und Übergangsunterstützung. Der Anbieter exportiert exportierbare Schlüssel in Standardformaten und unterstützt die Migration für einen definierten Zeitraum zu festgelegten Sätzen. Vereinbaren Sie, welche Schlüssel nicht exportierbar sind und wie Ihr Ausstieg für sie aussieht.
• Rückgabe und Löschung von Daten. Löschung von Mandantendaten, Schlüsseln und Protokollen nach dem Ausstieg, mit schriftlicher Bestätigung und Frist.
• Service Level. Verfügbarkeitsziel, Support-Reaktionszeiten, Service-Gutschriften und Kündigungsrecht bei wiederholten Verstössen.
• Sicherheitspflichten. Fristen für Vorfallmeldungen, Auditrechte, Zugang zu Zertifizierungsberichten und Zusammenarbeit mit Ihren Aufsichtsbehörden, einschliesslich der DORA-Vorgaben zu IKT-Drittdienstleistern, soweit anwendbar.
• Unterauftragnehmer und Standort. Vorabinformation und Widerspruchsrecht bei neuen Unterauftragnehmern oder Verlagerung der Schlüsselspeicherung.
• Recht und Gerichtsstand. Anwendbares Recht und Gerichtsstand sowie die Pflichten des Anbieters, wenn eine Behörde Daten verlangt.
• Escrow und Kontinuität. Hinterlegung von Software oder Schlüsselwiederherstellung für den Fall der Geschäftsaufgabe und eine Mindest-Supportdauer für die gelieferte Version.
• Preisschutz. Obergrenzen für jährliche Erhöhungen und für Entgelte bei wachsender Schlüssel- oder Operationszahl.

---

Einleitungstext zum Kopieren

Betreff: Ausschreibung Key-Management-System (KMS). [Organisation] wählt eine Key-Management-Lösung aus, um Lebenszyklus, Verwahrung, Zugriffskontrolle und Audit kryptografischer Schlüssel über [Cloud-Plattformen, SaaS-Anwendungen, Datenbanken und Infrastruktur] zentral zu steuern. Die Lösung muss die Schlüssel unter der Kontrolle von [Organisation] halten, externe Schlüsselverwaltung für [Microsoft 365, AWS, Azure, Salesforce, Snowflake, Oracle, SQL Server] unterstützen, Standardschnittstellen (KMIP und PKCS#11) und eine Administrations-API bereitstellen sowie manipulationssichere Audit-Protokolle, Quorum-Freigaben für sensible Operationen, Hochverfügbarkeit und einen dokumentierten Ausstiegsweg bieten. Die Angebote müssen die Anforderungsgruppen in Anlage A (Schlüssel-Lebenszyklus, Schlüsselverwahrung und -schutz, Integrationen, Kryptografie, Zugriffskontrolle und Quorum, Audit und Monitoring, Verfügbarkeit und Disaster Recovery, Bereitstellung und Souveränität, Anbieter und Support) anhand der Erfüllungsskala und der geforderten Nachweise beantworten. Die in die engere Wahl genommenen Anbieter nehmen an einem Proof of Concept in der Umgebung von [Organisation] teil. Die Angebote werden nach dem gewichteten Modell in Anlage B bewertet. Abgabefrist: [Datum]; Fragen an [Kontakt] bis [Datum].

---

FAQ

Q: Was gehört in eine KMS-Ausschreibung?

Eine KMS-Ausschreibung enthält den Umfang, eine Bestandsaufnahme von Schlüsseln und Plattformen, einen nach Lebenszyklus, Verwahrung, Integrationen, Kryptografie, Zugriffskontrolle, Audit, Verfügbarkeit, Bereitstellung und Anbieter-Support gegliederten Anforderungskatalog, ein gewichtetes Bewertungsmodell, einen Proof-of-Concept-Plan sowie Vertrags- und Ausstiegsklauseln. Jede Anforderung braucht eine Priorität und den Nachweis, den der Anbieter liefern muss.

Q: Wie formuliere ich KMS-Anforderungen, die keinen Anbieter bevorzugen?

Formulieren Sie Anforderungen als prüfbare Ergebnisse, etwa «Rotation hält alte Versionen zur Entschlüsselung verfügbar», nicht als Produktfunktionen. Stufen Sie architekturspezifische Punkte, wie Multi-Party Computation oder ein bestimmtes HSM, als Erweitert ein und bewerten Sie sie als Bonus. Legen Sie die Gewichte fest, bevor Sie eine Antwort lesen.

Q: Was unterscheidet eine KMS-Ausschreibung von einer HSM-Ausschreibung?

Eine KMS-Ausschreibung umfasst Lebenszyklus, Richtlinien, Integrationen und Audit über Systeme hinweg. Eine HSM-Ausschreibung konzentriert sich auf die Hardwaregrenze: Zertifizierung, Leistung, Bauform und Manipulationsschutz. Die meisten Projekte brauchen beides; eine KMS-Ausschreibung sollte fragen, welche Hardware-Backends unterstützt werden und welches Zertifikat jedes hat.

Q: Welche KMS-Integrationen sollte ich fordern?

Fordern Sie nur Plattformen, die Sie in den nächsten 12 Monaten nutzen werden, und verlangen Sie je Plattform einen Leitfaden und einen Referenzkunden. Typische Listen umfassen Microsoft 365 DKE oder Customer Key, AWS XKS, externe Schlüsselverwaltung in Azure, Salesforce, Snowflake, Oracle TDE, SQL Server EKM, VMware und Secrets-Plattformen wie HashiCorp Vault oder OpenBao.

Q: Wie lange sollte ein KMS-Proof-of-Concept dauern?

Üblich sind zwei bis vier Wochen, genug, um Bereitstellung, zwei Integrationen, Rotation, Quorum-Freigabe, Wiederherstellung und Failover auf Ihren eigenen Workloads zu testen. Legen Sie zuerst Bestehens- und Nichtbestehenskriterien fest und messen Sie neben dem Ergebnis auch den Aufwand.

Q: Sollte Post-Quanten-Unterstützung 2026 ein Muss sein?

Für die meisten Käufer ist sie ein Soll: Fordern Sie Unterstützung für ML-KEM (FIPS 203), ML-DSA (FIPS 204) und SLH-DSA (FIPS 205) oder eine datierte Roadmap, und stufen Sie hybride Modi und richtliniengesteuerte Krypto-Agilität als Erweitert ein. Müssen Ihre Daten viele Jahre vertraulich bleiben, erhöhen Sie die Priorität.

Q: Wie bewerte ich MPC-basierte Schlüsselverwaltung gegenüber einem HSM in einer Ausschreibung?

Richten Sie die Anforderung am Ergebnis aus, zum Beispiel «kein einzelner Administrator, Knoten oder Gerät kann einen vollständigen Schlüssel nutzen» und «FIPS-140-3-Validierung, wo vorgeschrieben», und lassen Sie jede Architektur zeigen, wie sie das erfüllt. Vergleichen Sie die Latenz im PoC mit Ihrem Aufrufmuster. Siehe MPC und HSM.

Q: Gibt es eine fertige Fassung dieses Anforderungskatalogs?

Die Tabellen auf dieser Seite sind so aufgebaut, dass Sie sie in eine Tabellenkalkulation kopieren können, mit den IDs in der ersten Spalte. Wie bestimmte Anbieter diese Kriterien beantworten, zeigen unsere Kaufberatung zur besten KMS-Lösung und die Vergleichsseiten.

---

Quellen

• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
• NIST FIPS 140-3, Security Requirements for Cryptographic Modules
• NIST Cryptographic Module Validation Program
• NIST FIPS 203, ML-KEM
• NIST FIPS 204, ML-DSA
• NIST FIPS 205, SLH-DSA
• OASIS KMIP Specification Version 2.1
• OASIS PKCS #11 Specification Version 3.2
• AWS KMS Developer Guide: External key stores
• Verordnung (EU) 2022/2554 (DORA)
• Richtlinie (EU) 2022/2555 (NIS2)