Zusammenfassung

  • Der Cyber Safety Review Board forderte CEO und Verwaltungsrat auf, einen Plan mit konkreten Fristen zu veröffentlichen. Microsoft lieferte datierte Berichte, Ziele in Bandbreiten, namentlich genannte Führungskräfte und eine Vergütungskopplung; keine dieser Unterlagen erlaubt einem Dritten, die veröffentlichten Prozentzahlen nachzurechnen.
  • Die Abdeckung der Release-Pipelines fiel von 94 Prozent im November 2025 auf 90 Prozent im Juli 2026, was Microsoft mit einem erweiterten Messumfang erklärt. Eine Zahl, die sich mit ihrem eigenen Nenner verschiebt, ist keine Zusicherung – und doch wandert sie in genau dieser Form durch die Beschaffungsakten.

Der Bericht des Cyber Safety Review Board über die Exchange-Online-Intrusion im Sommer 2023 – das eingesehene Exemplar trägt ein Titelblattdatum vom 20. März 2024 – lässt sich auf seine erste Empfehlung zusammenziehen: „The CEO and Board should develop, and share publicly, a plan with specific timelines to make fundamental, security-focused reforms“ (CSRB-Bericht, Druckseite 19).

Dieses Instrument hat drei Eigenschaften, und sie müssen gemeinsam gelten. Es adressiert die Unternehmensspitze, nicht eine Engineering-Abteilung. Es verlangt konkrete Fristen, nicht ein laufendes Programm. Und es verlangt Öffentlichkeit, also einen Leser, der urteilen kann. Zwei von drei genügen nicht.

Am 3. Mai 2024 antwortete Microsoft mit einer Reihe von 100-Prozent-Zielen, darunter diesem: „100% of access to source code and engineering systems infrastructure is secured through Zero Trust and least-privilege access policies.“ (Ankündigung vom 3. Mai 2024) Die Einhaltung sollte über Ziele und Schlüsselergebnisse gemessen werden. Auf der veröffentlichten Seite trägt jedoch keines dieser Ziele eine eigene Kalenderfrist, und keines nennt einen einzelnen Verantwortlichen.

Die Methode steht im Bericht vom April 2025 ohne Umschweife: „We calculated progress by recording the completed percentage of standards and key results, those defined initially and any additions.“ (Bericht April 2025, Druckseite 4) In die Sprache des Betriebs übersetzt: Der Nenner wächst, wenn das Unternehmen Arbeit hinzufügt. Das ist kein Betrug, das ist eine Definition – und genau sie macht die Zahl für einen externen Leser als Fortschrittsnachweis unbrauchbar.

Die Ergebnisse erscheinen anschließend in Bandbreiten statt in Punkten. Im April 2025 lagen die Ziele 1 bis 3 im Band von 95 bis 99 Prozent, die Ziele 4 und 5 im Band von 66 bis 94 Prozent. Im November 2025 blieben die Ziele 2 und 3 bei 95 bis 99 Prozent, während die Ziele 1, 4 und 5 auf 66 bis 94 Prozent fielen; das Unternehmen nannte ein erweitertes Inventar als Grund (Bericht November 2025). Im Juli 2026 ist Ziel 1 als „closed“ verzeichnet, Ziele 2 und 3 stehen bei 95 bis 99 Prozent, Ziele 4 und 5 bei 66 bis 94 Prozent (Bericht Juli 2026). Ein Band ist keine Zahl, und ein Abschluss ist kein Anlagenverhältnis: Beides lässt sich nicht nachrechnen.

Die Abdeckungszahlen dagegen sind datiert und vergleichbar – sofern man respektiert, was jeder Bericht misst. September 2024: 85 Prozent der Produktions-Build-Pipelines der kommerziellen Cloud nutzten zentral gesteuerte Pipeline-Vorlagen (Bericht September 2024). April 2025: 92 Prozent der Build-Pipelines, 54 Prozent der Release-Pipelines und 56 Prozent des Code-Signing-Zugriffs, beschränkt auf Produktionsmandanten-Identitäten. November 2025: 94 Prozent der Release-Pipelines mit gesteuerten Vorlagen und 89 Prozent Netzwerkisolierung. Juli 2026: 93 Prozent der kritischen und hochwertigen Build-Pipelines und 90 Prozent der Release-Pipelines (Trust-Center-Zusammenfassung Juli 2026).

Die Reihe der Release-Pipelines verdient langsames Lesen: 54 Prozent, dann 94 Prozent, dann 90 Prozent. Microsoft kommentiert die letzte Bewegung so: „Recent metric variation reflects expanded measurement scope, with final attribution under review.“ (PDF Juli 2026) Wer wissen will, ob die Kontrollen schlechter, besser oder nur neu definiert wurden, findet im Dokument keine Antwort. Das Unternehmen selbst schreibt, die Zuordnung werde noch geprüft.

Die meistzitierte Zahl ist von anderer Art: „achieving 99.5% detection and remediation of live secrets in code.“ (Ankündigung vom 10. November 2025) Der Text nennt weder Zähler noch Nenner noch Erhebungsmethode und sagt nicht, ob damit Abdeckung, Detektionsleistung oder abgeschlossene Behebung gemeint ist. Das ist eine Aussage des Unternehmens über sich selbst, keine geprüfte Trefferquote.

Die im Juli 2026 veröffentlichten Mengen verlangen dieselbe Vorsicht: mehr als 550.000 Instanzen kritischer und hochriskanter Open-Source-Schwachstellen behoben, und automatisierte Container-Patching-Prozesse, die monatlich rund drei Millionen Schwachstellen-Instanzen bearbeiten (Zusammenfassung Juli 2026). Eine Instanz ist keine eindeutige Schwachstelle und keine CVE; die Zahl 550.000 nennt kein Messfenster; und monatlicher Durchsatz ist keine Beseitigung eines Rückstands. Zwei weitere Angaben rahmen die Lektüre: Rund 80.000 Pipelines werden überwacht, und fünf der sieben großen Sicherheitslog-Kategorien erfüllten im April 2025 den Aufbewahrungsstandard (Bericht April 2025). Zudem unterscheiden sich die Bezugszeiträume: November 2025 zählt CVEs seit Januar 2025, während die Bug-Bounty-Zahlungen Juli 2024 bis Juni 2025 abdecken. Ein Veröffentlichungsdatum ist kein Stichtag.

Das Unternehmen räumt die Grenze selbst ein: „We do not disclose the full body of work we are undertaking to advance an objective (such as standards and key results)“ (Bericht November 2025). Das ist Offenheit. Und es ist der technische Grund, aus dem keine externe Prüfung allein mit diesen Dokumenten die Rechnung nachvollziehen könnte.

Es bleibt das Element, das einer Konsequenz am nächsten kommt. Satya Nadella kündigte im Mai 2024 an, Microsoft lege „part of the compensation of the senior leadership team on our progress towards meeting our security plans and milestones“ zugrunde (offizieller Blog vom 3. Mai 2024), im September 2024 wiederholt: „Microsoft’s senior leadership team now has security performance directly linked to compensation.“ (Fortschrittsupdate September 2024) Keines der eingesehenen Dokumente veröffentlicht Gewichtungen, Auslöseschwellen oder automatische Kürzungen, die an einen bestimmten Meilenstein gebunden sind. Eine Vergütungskopplung ohne Skala bleibt ein Prioritätssignal, keine vollstreckbare Klausel.

Auch die Governance hat Namen. CISO Igor Tsyganskiy führt den Cybersecurity Governance Council der Deputy CISOs; die Deputy CISOs und die Engineering-Teams tragen gemeinsam Verantwortung für Aufsicht, Risikomanagement und Berichterstattung; die Führungsreviews sind wöchentlich, die Updates an den Verwaltungsrat vierteljährlich, und Sicherheitsleistung fließt in Mitarbeiterbeurteilungen ein. Joy Chik ist als Executive Sponsor des Programms benannt (Ankündigung September 2024). Namentliche Aufsicht ist kein Register, das jedem Indikator einen Eigentümer und ein Datum zuordnet.

Zu würdigen ist auch, was tatsächlich existiert. Das Programm enthält mindestens eine Kalenderfrist: das Ziel, kritische Produkte und Dienste bis 2029 auf Post-Quanten-Kryptografie (PQC) umzustellen (Ankündigung vom 10. Juli 2026). Zu behaupten, alles sei undatiert, wäre falsch. Und der Anhang des April-Berichts 2025 markiert die CSRB-Empfehlungen 1 bis 4 als „complete“ – das ist Microsofts Einschätzung der eigenen Konformität, keine unabhängige Validierung.

Der jüngste Bericht steht auf dem Programm-Hub mit Datum Juli 2026, die zugehörige Ankündigung trägt den 10. Juli 2026 (Trust-Center-Hub). Die Taktung ist ein Versprechen, kein Kalender: „We plan to keep ourselves accountable and provide the latest SFI news to customers, partners, and the security community through regular updates.“ Eine feste Veröffentlichungsfrist steht auf dieser Seite nicht, und die Seite selbst ist veränderbar.

Bei der Frage, die alles entscheidet – wer außerhalb von Microsoft diese Prozentzahlen bestätigt –, ist die ehrliche Antwort eng: In den elf Dokumenten, die ich zu den angegebenen Abrufdaten gelesen habe, fand sich keine unabhängige Bestätigung der veröffentlichten Prozentzahlen. Diese elf sind der CSRB-Bericht, vier ausführliche Fortschrittsberichte, vier datierte Microsoft-Ankündigungen, die Trust-Center-Zusammenfassung vom Juli 2026 und der Programm-Hub. Interne Tests, Standards-Zuordnungen und die frühere Incident-Prüfung des Boards sind keine unabhängige Zusicherung über spätere Fortschrittszahlen.

Fehlen in diesem Set ist kein Beweis für Fehlen anderswo.

Was das über unsere bisherige Berichterstattung über dieses Unternehmen hinaus hinzufügt, gehört ohne Umschweife gesagt. Unsere sieben früheren Artikel behandelten es als Produkt- und Marktakteur: die Copilot-Konsolidierung (19. März 2026), die berichteten Manöver zwischen Microsoft, Amazon und OpenAI (19. März 2026), die CISA-Warnung nach dem Stryker-Angriff mit Bezug auf Intune-Administratorenkontrollen (19. März 2026), der Microsoft-365-Ausfall (23. Januar 2026), die 200-MW-Erweiterung mit G42 in den Emiraten (7. November 2025) und die Empfehlungen der britischen Wettbewerbsbehörde zum Cloud-Markt (1. August 2025). Keiner prüfte, was nach einer externen Überprüfung an die Stelle eines durchsetzbaren Rechtsbehelfs tritt. Unser eigener Briefing zur Unverbindlichkeit des Boards endete dort, wo dieser Text beginnt: bei dem Instrument, das das Unternehmen an dessen Stelle gebaut hat. Der Eintrag zu Microsoft Corporation im BTW-Verzeichnis dient hier als Identitätsanker, nicht als Quelle operativer Fakten.

Die nützliche Frage ist deshalb nicht, ob Microsoft ernsthaft arbeitet – die Dokumente zeigen Arbeit, benannte Personen und Zehntausende instrumentierte Pipelines. Die Frage ist, wozu eine selbst veröffentlichte Prozentzahl verpflichtet. In einem Einkaufsvertrag wirkt eine Erfüllungsquote wie eine Garantie; im Jahresbericht wie eine Kontrolle; in einer Police wie ein gemessenes Risiko. In allen drei Fällen kauft der Leser eine Schlussfolgerung, die nur der Verkäufer erzeugen kann. Ein Maß, das der Gemessene selbst definiert, berechnet und kommentiert, ist keine Prüfung. Es ist eine Selbstauskunft mit Nachkommastellen.