Einschränkungen des AWS Certificate Manager: Wo ACM für Enterprise-PKI an seine Grenzen stößt.

AWS Certificate Manager (ACM) ist ein verwalteter Dienst, der Zertifikate bereitstellt, implementiert und erneuert. TLS/SSL-Zertifikate Für AWS-integrierte Dienste hat es sich aus gutem Grund zum Standard-Ausgangspunkt für TLS-Zertifikate im AWS-Ökosystem entwickelt: Es ist für integrierte Dienste kostenlos, vollständig verwaltet und nach der Konfiguration praktisch unsichtbar. Die Zertifikatsverwaltung beschränkt sich jedoch selten vollständig auf AWS.

Da Unternehmen ihre Workloads zunehmend über mehrere Clouds, lokale Infrastrukturen und eine wachsende Anzahl von Zertifizierungsstellen verteilen, lautet die Frage nicht mehr „Ist ACM gut?“, sondern „Wo stößt ACM an seine Grenzen?“. Dieser Blog beantwortet diese Frage. Er zeigt auf, wo ACM tatsächlich seinen Platz hat und wo die praktischen Grenzen liegen. PKI Teams stoßen auf Probleme, sobald sie über AWS-native Dienste hinausgehen, auf die wirtschaftlichen Gegebenheiten, die diese Grenzen bedingen, und darauf, wie eine herstellerneutrale CLM-Plattform die Lücken füllt, insbesondere da die Gültigkeitsdauer von Zertifikaten immer kürzer wird und der Übergang nach dem Quantenzeitraum die Anforderungen erhöht.

Wo ACM passt und wo nicht

Wenn Ihre gesamte Arbeitslast hinter einem Application Load Balancer liegt, der von Amazon CloudFront gesteuert und über Amazon API Gateway bereitgestellt wird, ist AWS Certificate Manager (ACM) kaum zu übertreffen. Er stellt kostenlos öffentliche TLS-Zertifikate für diese integrierten Dienste aus, kümmert sich um deren Erneuerung und verursacht nahezu keinen Betriebsaufwand. Für reine AWS-native Teams mit einer begrenzten Infrastruktur ist er einer der besten Managed Services von AWS.

Die Probleme beginnen, sobald Ihre Zertifikatsarchitektur über die Grenzen von AWS hinausgeht. Die meisten Unternehmen, mit denen wir bei Encryption Consulting zusammenarbeiten, sind keine reinen AWS-Anwender. Sie nutzen eine Mischung aus lokalem Microsoft Active Directory (AD CS), Drittanbieter-Zertifizierungsstellen wie DigiCert oder Entrust für öffentlich vertrauenswürdige Zertifikate, HashiCorp Vault PKI für Service Mesh und DevOps-Workloads sowie einer Vielzahl von Workloads auf F5 BIG-IP, NGINX, Apache Tomcat und IIS, die in keiner Verbindung zu AWS stehen.

Laut dem Flexera-Bericht „State of the Cloud 2024“ haben rund 89 % der Unternehmen Multi-Cloud-Lösungen eingeführt, und Gartner prognostiziert, dass bis 2027 über 90 % der Unternehmen Hybrid-Cloud-Lösungen nutzen werden. In diesem Umfeld ist ein CLM-Tool, das nur einen Cloud-Anbieter in einer Region verwalten kann, bestenfalls eine Teillösung.

Dieser Blogbeitrag erläutert die praktischen Einschränkungen von ACM, auf die PKI-Teams bei der Implementierung in Unternehmen stoßen, die damit verbundenen wirtschaftlichen Aspekte und wie eine herstellerneutrale CLM-Plattform wie die von Encryption Consulting Abhilfe schaffen kann. CertSecure Manager schließt die Lücken, die ACM offen lässt.

ACM vs. AWS Private CA: Eine kurze Auffrischung

Bevor wir fortfahren, ist es wichtig, zwei AWS-Dienste zu unterscheiden, die oft verwechselt werden. AWS hat „ACM Private CA“ im September 2022 in „AWS Private CA“ umbenannt, und diese Unterscheidung ist relevant, wenn Sie Preisinformationen lesen oder Registrierungsprozesse entwerfen.

AWS Certificate Manager (ACM) ist der Lebenszyklusdienst. Er stellt öffentliche TLS-Zertifikate von Amazons öffentlicher Zertifizierungsstelle aus, stellt sie bereit und erneuert sie und dient gleichzeitig als Verwaltungsschicht für private Zertifikate, die von AWS Private CA ausgestellt werden. Von ACM ausgestellte öffentliche Zertifikate, die ausschließlich mit integrierten AWS-Services (ELB, CloudFront, API Gateway, App Runner usw.) verwendet werden, sind kostenlos.

AWS Private CA ist die verwaltete private Zertifizierungsstelleninfrastruktur. Sie betreibt Ihre Zertifizierungsstellenhierarchie auf FIPS 140-2 Hardwaregeschützte Schlüssel, allerdings fällt eine monatliche Gebühr pro Zertifizierungsstelle zuzüglich Gebühren pro ausgestelltem Zertifikat an.

Die folgenden Einschränkungen gelten für beide, da sie für die meisten Teams als einheitliches Erlebnis bereitgestellt werden.

Die realen Grenzen des AWS Certificate Manager

1. Das kostenlose öffentliche Zertifikat gehörte Ihnen nie wirklich.

Das Hauptmerkmal von ACM ist das kostenlose öffentliche TLS-Zertifikat. Der private Schlüssel für ein „Standard“-ACM-Zertifikat lässt sich jedoch nicht exportieren. Das Zertifikat kann nur an ACM-integrierte AWS-Services gebunden werden. Wenn Ihr TLS-Terminierungsendpunkt etwas anderes ist (z. B. eine EC2-Instanz mit NGINX, ein lokales F5-System, ein Azure App Service, ein GCP Load Balancer, ein Drittanbieter-CDN oder eine Hardware-Appliance), kann das kostenlose ACM-Zertifikat dort nicht eingesetzt werden. Sie müssen daher parallele Workflows ausführen: einen von ACM verwalteten Workflow für AWS-integrierte Services und einen komplett separaten Prozess für alle anderen Services. Dies führt zu einem sich ständig erhöhenden Betriebsaufwand.

AWS Dies wurde teilweise berücksichtigt. Im Juni 2025 werden exportierbare öffentliche Zertifikate eingeführt, mit denen man den privaten Schlüssel herunterladen und das Zertifikat überall einsetzen kann. Die Flexibilität ist real, aber die wirtschaftlichen Rahmenbedingungen verändern sich drastisch:

• 7 US-Dollar pro vollqualifiziertem Domainnamen (FQDN), fällig bei der Ausstellung und erneut bei jeder Verlängerung.
• 79 US-Dollar pro Wildcard-Name (z. B. *.yourdomain.com), jeweils bei der Ausstellung und bei jeder Verlängerung.
• ACM-Zertifikate haben eine maximale Gültigkeitsdauer von 13 Monaten und können nach 11 Monaten verlängert werden, sodass eine Verlängerung heutzutage ungefähr einmal im Jahr erfolgt.

Das klingt bescheiden, bis man die Rechnung im Unternehmensmaßstab durchrechnet. CA/Browser-Foren Durch die schrittweise Reduzierung der Gültigkeitsdauer (200 Tage ab März 2026, 100 Tage ab März 2027, 47 Tage ab März 2029) werden die Erneuerungen innerhalb von drei Jahren von jährlich auf etwa alle sechs Wochen verkürzt. Multipliziert man dies mit 500 oder 5,000 FQDNs, so werden die Kosten für den „kostenlosen Zertifikatsmanager“ zu einem wiederkehrenden Kostenfaktor pro Zertifikat, der linear mit der Anzahl der Zertifikate skaliert.

Die Kernaussage ist nicht, dass exportierbare Zertifikate unvernünftig wären, sondern dass das Preismodell von ACM für die interne Nutzung bei AWS konzipiert wurde. Sobald man es außerhalb dieses Rahmens einsetzt, ändert sich das Kostenmodell grundlegend, und man zahlt nun Gebühren pro Zertifikat zusätzlich zu der Automatisierungsinfrastruktur, die man für die Bereitstellung noch aufbauen muss.

2. Die Automatisierung endet an der AWS-Grenze

Innerhalb von AWS ist ACM hervorragend. Erneuerungen für ELB, CloudFront, API Gateway und ähnliche Dienste werden automatisch durchgeführt. Das Zertifikat wird rotiert, der integrierte Dienst erkennt das neue Zertifikat, und der Administrator muss nichts weiter tun.

Außerhalb von AWS führt ACM keine Bereitstellungen durch. Für exportierbare Zertifikate, die für einen lokalen F5-Server, einen NGINX-Server, einen Citrix ADC, einen Kubernetes-Ingress außerhalb von EKS oder einen anderen Nicht-AWS-Endpunkt bestimmt sind, endet die Verantwortung von ACM mit dem API-Aufruf. Sie können Amazon EventBridge abonnieren, um Benachrichtigungen zur Zertifikatserneuerung zu erhalten. Die eigentliche Bereitstellung, die Schlüsselrotation auf dem Gerät, die Bindung des virtuellen Servers an den Load Balancer, der Neustart des zugehörigen Dienstes und die Validierung des neuen Zertifikats liegen jedoch vollständig in Ihrer Verantwortung.

Das bedeutet benutzerdefinierte Skripte, benutzerdefinierte IAM-Richtlinien, benutzerdefinierte Fehlerbehandlung und ein benutzerdefiniertes Audit-Protokoll. Jedes Team, das wir beim Aufbau dieser Lösung unterstützt haben, musste letztendlich dieselbe Steuerungsebene neu entwickeln: eine Warteschlange für Zertifikatsereignisse, einen Worker, der das neue Zertifikat abruft, eine Konnektorbibliothek für jeden Zielendpunkttyp, einen Wiederholungsmechanismus für Teilfehler und einen Rollback-Plan, falls das neue Zertifikat die Anwendung beeinträchtigt. Genau das sollte eine speziell entwickelte CLM-Plattform leisten, und genau das leistet ACM nicht, sobald man die AWS-Edge-Umgebung verlässt.

3. Der Lagerbestand ist nach Konto und Region fragmentiert.

Die Inventarverwaltung von ACM ist auf ein einzelnes AWS-Konto und eine einzelne Region beschränkt. Wenn Sie mit 12 Konten und 4 Regionen arbeiten, müssen Sie 48 logische Zertifikatsinventare verwalten, und es gibt keine integrierte Übersicht über diese.

Die CloudFront-Beschränkung verschärft das Problem. Selbst wenn Ihre Anwendung vollständig in ap-south-1 oder eu-west-1 ausgeführt wird, CloudFront benötigt ein Zertifikat im Netzwerk us-east-1.Eine typische Multi-Region-Bereitstellung führt dazu, dass dasselbe logische Zertifikat in zwei Regionen verwendet wird: eines in us-east-1 für das CDN und eines in der jeweiligen Anwendungsregion für den Load Balancer. Es gibt keine automatische Synchronisierung, kein gemeinsames Zertifikatsinventar und keine native regionsübergreifende Ansicht. In der Praxis erhalten identische Domains separate Zertifikate, die unabhängig voneinander ausgestellt und erneuert werden, ohne dass ein gemeinsames Zertifikatsinventar diese miteinander verbindet.

Für Sicherheits- und Audit-Teams stellt diese Fragmentierung ein echtes Problem dar. Eine unternehmensweite Richtlinie („Keine RSA-2048-Zertifikate nach dem 1. Januar 2027“ oder „Alle Zertifikate müssen einen registrierten Inhaber haben“) lässt sich nicht durchsetzen, wenn kein zentrales Inventar vorhanden ist, auf das sich die Durchsetzung stützt. Auch eine kryptografische Sicherheitsbewertung im Vorfeld ist nicht möglich. Post-Quantenmigration Wenn Sie nicht sehen können, was Sie haben. Und Schattenzertifikate, jene, die ein Entwickler vor zwei Jahren in einer Region beantragt hat, die niemand mehr überwacht, sind genau die, die Samstagnacht-Ausfälle verursachen.

4. Die Preise für private AWS-Zertifizierungsstellen steigen schnell an.

Die veröffentlichten Preise für private AWS-Zertifizierungsstellen Es ist zwar einfach, aber die Zahlen summieren sich schneller, als die meisten Teams erwarten:

• 400 US-Dollar pro privatem CA pro Monat für den allgemeinen Verwendungszweck (beliebige Gültigkeitsdauer)
• 50 US-Dollar pro privater Zertifizierungsstelle und Monat für den Modus mit kurzfristiger Zertifikatsgültigkeit (maximal 7 Tage Gültigkeit)
• Gebührenstaffelung pro Zertifikatsausstellung durch eine allgemeine Zertifizierungsstelle: 0.75 $ für die ersten 1,000, 0.35 $ für die nächsten 9,000 und 0.001 $ für über 10,000
• 0.06 US-Dollar pro Zertifikat und Monat für OCSP-Antworten (wird nur für Zertifikate berechnet, die tatsächlich OCSP-Anfragen erhalten)

Bei einer typischen zweistufigen Hierarchie (eine Offline-Root- und eine Online-Ausstellungsstelle) belaufen sich die Kosten vor der Ausstellung eines einzigen Zertifikats auf 800 US-Dollar pro Monat. Mit regionsübergreifender Hochverfügbarkeit können die monatlichen Kosten leicht 1,600 bis 2,400 US-Dollar erreichen. Für einen Anwendungsfall in der Fertigung oder im IoT-Bereich, bei dem monatlich 50,000 Gerätezertifikate ausgestellt werden, sind die Kosten pro Zertifikat dank des Mengenrabatts angemessen. Die monatliche Gebühr pro Zertifizierungsstelle ist jedoch nicht skalierbar: Jede regionale Zertifizierungsstelle, jede separate Vertrauenshierarchie und jede Testumgebung kostet pauschal 400 US-Dollar pro Monat.

Vergleichen Sie dies mit einem selbstgehosteten Microsoft AD CS-HierarchieBei AWS Private CA sind die Grenzkosten pro Zertifikat nach der ersten Bereitstellung praktisch null, während bei Managed-PKI-Lösungen die Kosten anders verteilt werden. AWS Private CA ist zwar komfortabel, aber nicht die günstigste Lösung, und das Kostenmodell begünstigt die Konsolidierung in einer einzigen Zertifizierungsstelle anstatt der von vielen Sicherheitsteams gewünschten Funktionstrennung.

5. Das Compliance-Reporting ist eine Angelegenheit, die man selbst gestalten muss.

ACM erstellt keine vorgefertigten Konformitätsberichte auf Zertifikatsebene für PCI DSS, HIPAA, SOC 2, DORAoder ein anderes Framework. AWS bietet ergänzende Funktionen (AWS Config-Regeln können nicht konforme ACM-Zertifikate erkennen, Security Hub verfügt über Standardzuordnungen, die Befunde kennzeichnen, AWS Artifact liefert die AWS-Service-Level-Compliance-Berichte), aber keines davon ist eine sofort einsatzbereite Lösung, die mir nach Abteilung den Audit-Status jedes Zertifikats, den Eigentümer, den verwendeten Algorithmus, das Ablaufdatum und etwaige Abweichungen von den Richtlinien bei der Ausstellung anzeigt.

Für regulierte Unternehmen wird diese Lücke bei Audits sichtbar. Das Compliance-Team fordert einen Bericht über alle relevanten TLS-Zertifikate mit Schlüssellänge, SAN-Einträgen, Inhaber, ausstellender Zertifizierungsstelle, Ablaufdatum und Einhaltung der Richtlinien. Mit ACM allein muss dieser Bericht aus einer Kombination von describe-certificate-Aufrufen, benutzerdefinierten Lambda-Funktionen, AWS-Config-Exporten und einer manuell bearbeiteten Tabelle erstellt werden. Der ausgereifte CLM-Workflow sieht vor, dass der Bericht per Knopfdruck wöchentlich an den Posteingang des Auditors geliefert wird.

6. Anbieterabhängigkeit beeinträchtigt die Krypto-Agilität

In den nächsten Jahren werden zwei Branchenverschiebungen zusammenlaufen, und beide erfordern Krypto-Agilität:

• Das CA / Browser Forum Stimmzettel SC-081v3Die im April 2025 verabschiedete Regelung reduziert die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate von derzeit 398 Tagen auf 200 Tage (März 2026), 100 Tage (März 2027) und 47 Tage (März 2029). Das Zeitfenster für die Wiederverwendung der Domainvalidierung sinkt bis März 2028 auf 10 Tage.
• NIST's Post-Quanten-Kryptographie Der Übergangsplan sieht vor, dass Unternehmen die älteren RSA- und ECC-Standards bis 2030 abschaffen und bis 2035 vollständig ersetzen. ML-DSA und ML-KEM (FIPS 204 und 203) sind die neuen Standards. AWS hat damit begonnen, ML-DSA-Unterstützung in AWS KMS und AWS Private CA zu integrieren. Der umfassendere operative Austausch der Algorithmen in einer gesamten IT-Landschaft geht jedoch über eine einzelne Zertifizierungsstelle hinaus.

Krypto-Agilität Die Möglichkeit, Zertifizierungsstellen, Algorithmen, Schlüssellängen, Gültigkeitsdauern und Bereitstellungsziele ohne Umstrukturierung der Steuerungsebene auszutauschen, ist entscheidend. Ist Ihre Zertifikatsverwaltung architektonisch an einen einzigen Anbieter gebunden, fehlt Ihnen die nötige Krypto-Agilität – Sie sind abhängig. Sobald AWS das Preismodell ändert, einen Servicevertrag anpasst, eine Funktion einstellt oder sich Ihre Geschäftsanforderungen ändern und Sie Workloads zu Azure oder GCP migrieren müssen, entsprechen die Kosten für die Auflösung dieser Abhängigkeit den Kosten für den Neuaufbau Ihres CLM-Stacks. Das ist eine ungünstige Ausgangslage für die Zukunft. 47-Tag Mandat und die PQC-Migration.

Das 47-Tage-Mandat verschärft jede Lücke

All das wird schwieriger, je kürzer die Gültigkeitsdauer des Zertifikats wird. Heute wird ein typisches TLS-Zertifikat einmal jährlich erneuert. Im März 2026 wird dies etwa alle sechseinhalb Monate der Fall sein. Im März 2027 alle dreieinhalb Monate. Im März 2029 alle sechseinhalb Wochen.

Das entspricht einer achtfachen Steigerung der Verlängerungshäufigkeit in weniger als drei Jahren. Jede Lücke in der Automatisierung von ACM, jede Region, die separat geprüft werden muss, jeder Endpunkt außerhalb der AWS-Grenzen, der ein manuelles Bereitstellungsskript erfordert, jeder Compliance-Bericht, der manuell erstellt wird – all dies skaliert linear mit der Verlängerungshäufigkeit. Ein Workflow, der bei einer Gültigkeitsdauer von 12 Monaten lästig ist, wird bei 47 Tagen betrieblich nicht mehr tragbar.

Genau deshalb hat sich die Diskussion in der Branche so stark in Richtung geschlossener, herstellerneutraler CLM-Systeme verlagert. Nicht etwa, weil ACM schlecht wäre, sondern weil eine Teilautomatisierung dem hohen Auftragsvolumen einfach nicht standhält.

Wie CertSecure Manager diese Lücken schließt

CertSecure ManagerDie CLM-Plattform von Encryption Consulting wurde von PKI-Experten entwickelt, die täglich mit genau diesen Szenarien in Kundenprojekten konfrontiert sind. Wo ACM an der AWS-Grenze endet, setzt CertSecure Manager ein:

• Multi-CA, herstellerneutral von Grund auf. CertSecure Manager verbindet sich über eine einzige Konsole mit Microsoft AD CS, AWS Private CA, HashiCorp Vault PKI, DigiCert, Entrust und anderen öffentlichen und privaten Zertifizierungsstellen. Sie erhalten ein einheitliches Zertifikatsinventar, eine einheitliche Richtlinienebene und eine einheitliche Erneuerungswarteschlange – unabhängig davon, welche Zertifizierungsstelle das Zertifikat ausgestellt hat oder in welcher Cloud die Workload ausgeführt wird.
• Geschlossene Automatisierung jenseits von AWS. Erneuerungsagenten für Apache, Tomcat, IIS, F5 BIG-IP, NGINX und kundenspezifische interne Anwendungen übernehmen den Bereitstellungsschritt, den ACM nicht abdeckt. CertSecure Manager Orchestrator für F5, das im Rahmen unserer Partnerschaft im F5 Application Delivery and Security Platform Partner Program entwickelt wurde, ordnet automatisch jedes Zertifikat dem richtigen F5 Virtual Server SSL-Profil zu und eliminiert so den manuellen Bindungsschritt, der die meisten zertifikatsbedingten Ausfälle von F5 verursacht.
• Standardisierte Registrierungsprotokolle. REST-API- und ACME-Endpunkte ermöglichen die automatische Registrierung von Cloud-nativen und DevOps-Workloads, genau wie bei Let's Encrypt oder jedem anderen Standard-ACME-Endpunkt. Das bedeutet, dass cert-manager in Kubernetes, certbot auf einem Linux-Host oder eine benutzerdefinierte CI/CD-Pipeline alle über dasselbe Protokoll registrieren können.
• Zentrale Transparenz über Cloud und On-Premises hinweg. Die automatisierte Zertifikatserkennung scannt Ihre Umgebung, erstellt ein einheitliches Inventar über AWS-Konten und -Regionen, Azure, GCP, On-Premises und Kubernetes-Cluster hinweg und stellt Eigentümerschaft, Algorithmus, Gültigkeit und Richtlinienkonformität für jedes Zertifikat in einem Dashboard dar.
• Richtliniendurchsetzung und Genehmigungen. Globale und abteilungsspezifische Richtlinien umfassen die Mindestschlüssellänge, zulässige Algorithmen, FIPS-konforme Beschränkungen, Regeln zur Verwendung von Wildcards, Regeln zur Wiederverwendung von CSRs, DNS-Whitelisting zur Domainvalidierung sowie M-of-N-Genehmigungsworkflows für hochsichere Zertifikatvorlagen. Diese Richtlinien werden zum Zeitpunkt der Ausstellung und nicht nachträglich durchgesetzt.
• Auditfähige Compliance-Berichterstattung. Geplante Berichte, die wöchentlich oder monatlich an den Compliance-Posteingang geliefert werden, mit den für PCI DSS erforderlichen Zertifikatsdetails. HIPAASOC 2- und DORA-Audits fordern dies tatsächlich. Kein manueller Export, kein Zusammenführen von Tabellenkalkulationen.
• Integrierte Krypto-Agilität. Da CertSecure Manager CA-agnostisch ist, handelt es sich beim Austausch der zugrunde liegenden CA, der Umstellung auf einen neuen Schlüsselalgorithmus oder der Migration von einem Anbieter zu einem anderen lediglich um eine Richtlinienänderung und nicht um eine Neuarchitektur. Dies ist sowohl im Hinblick auf die 47-tägige Frist als auch auf die PQC-Migration von Bedeutung.

Wann ACM ausreicht und wann nicht

Nicht jedes Team benötigt eine vollständige CLM-Plattform. Hier ein praktischer Überblick darüber, wann ACM allein ausreicht und wann es nicht mehr genügt:

Szenario	ACM allein	Anbieterneutrales CLM
Ein einzelnes AWS-Konto, eine einzelne Region, vollständig AWS-native Workloads	Ja	Nein
Weniger als 100 Zertifikate, alle für ACM-integrierte Dienste	Ja	Nein
Multi-Cloud (AWS + Azure und/oder GCP)	Nein	Ja
Hybrid-Cloud mit On-Premise-Infrastruktur (AD CS, F5, NGINX, Apache, IIS)	Nein	Ja
Mehr als 1,000 Zertifikate über mehrere Zertifizierungsstellen und Umgebungen hinweg	Nein	Ja
Strenge Einhaltung der Vorschriften (PCI DSS, HIPAA, SOC 2, DORA, regulierte Branchen)	Nein	Ja
Kubernetes und containerisierte Workloads über Clouds hinweg	Nein	Ja
Vorbereitung auf eine 47-tägige Gültigkeitsdauer mit beliebigen Nicht-AWS-Endpunkten	Nein	Ja
Annäherung an die PQC-Migration bei heterogener CA-Landschaft	Nein	Ja

Das Muster ist einfach. ACM ist ausreichend, wenn die Zertifikatslage begrenzt, AWS-nativ und klein ist. Sobald eine dieser drei Bedingungen nicht mehr erfüllt ist, schlägt sich die alleinige Verwendung von ACM in höherer betrieblicher Komplexität, aufwändiger Audits und einem erhöhten Ausfallrisiko nieder.

Fazit

ACM ist innerhalb seiner vorgesehenen Rahmenbedingungen ein wirklich guter Dienst. Der Fehler liegt in der Annahme, dass diese Rahmenbedingungen der Realität in Unternehmen entsprechen. Die meisten Organisationen arbeiten mit mehreren Clouds, mehreren Zertifizierungsstellen und einer Vielzahl lokaler Endpunkte, die ACM nicht erreichen kann. Die 47-tägige Gültigkeitsdauer von TLS und die Migration zu PQC werden die bestehenden Lücken in der Automatisierung, Transparenz und Richtliniendurchsetzung von ACM deutlich verschärfen.

Der richtige Ansatz besteht darin, ACM dort einzusetzen, wo es seine Stärken hat (kostenlose öffentliche Zertifikate für AWS-integrierte Dienste, unkomplizierte Verlängerungen innerhalb der AWS-Umgebung), und darüber eine herstellerneutrale CLM-Plattform zu implementieren, die alle Aufgaben übernimmt, für die ACM nicht konzipiert wurde. So erhalten Sie die operative Einfachheit von ACM dort, wo es funktioniert, und die umgebungsübergreifende Automatisierung, Governance und Krypto-Agilität, die Sie überall sonst benötigen.