All you need is Love? Nein. All you need is Escrow!

Ein Escrow-Service (Treuhandservice) bezeichnet die Hinterlegung kritischer Vermögenswerte (z. B. Patente, Informationen, Verträge) bei einem neutralen Dritten, der diese nur unter klar definierten Auslösebedingungen freigibt.

Während es bei der Hinterlegung bei Dritten zur Wahrung von Sicherheit oft um Waren oder Geld geht, ist der digitale Escrow-Service etwas besonderes. Mehr dazu findet sich auch bei: https://ose-international.org/software-escrow

Bei Escrow-Services mit Fokus auf Informationssicherheits‑ und Risikomanagement (z. B. im Kontext von ISO/IEC 27001, BSI IT‑Grundschutz) im IT‑ und ISMS‑Kontext handelt es sich typischerweise um:

• Quellcode

• Build- und Deploymentskripte

• Dokumentation

• Kryptografische Schlüssel

• Konfigurationsdaten

• Cloud‑Zugriffsartefakte

Ziel ist es, die Betriebs‑ und Sicherheitskontinuität sicherzustellen, falls ein Lieferant oder Dienstleister ausfällt. Die Lieferkette kann damit also besser abgesichert werden.

Relevanz für das Informationssicherheitsmanagement (ISMS)

Escrow-Services adressieren mehrere klassische ISMS‑Schutzziele und Risiken und liefern einen Beitrag zu den Schutzzielen (CIA-Triade) wie Verfügbarkeit (sie unterstützen die Sicherstellung des Weiterbetriebs bei Lieferantenausfall), die Integrität (wird mit Versionskontrolle und abgesicherter Hinterlegung) gesichert sowie die Vertraulichkeit (mit Regelungen zum Zugriff mit einer Beschränkung auf vertraglich festgelegte Ereignisse). Escrow wirkt als präventive und korrektive Risikobehandlungsmaßnahme.

Rolle von Escrow im Rahmen etablierter Standards

Bei ISO/IEC 27001 / 27002 – Controls lassen sich Escrow-Services mehreren Controls zuordnen, u. a.:

• A.5.19 und 20 (Beziehung zu Lieferanten)

• A.5.21 (Informationssicherheit in Lieferketten)

• A.5.30 (IKT‑Bereitschaft für Business Continuity)

• A.8.12 (Datenleckprävention – indirekt)

Escrow fungiert als mögliche Risikobehandlungsmaßnahme im Annex‑A‑Mapping!

BSI IT‑Grundschutz

Im IT‑Grundschutz unterstützt Escrow insbesondere:

• ORP.4 Identitäts- und Berechtigungsmanagement

• DER.4 Notfallmanagement

• CON.3 Datensicherungskonzept

Typische Digital-Escrow-Modelle aus ISMS-Sicht sind das klassische Software-Escrow mit

• Hinterlegung von Quellcode + Dokumentation

• Regelmäßige Updates (z. B. bei Releases)

• Technische Verifikation („Build‑Test“) und

• Absicherung individuell entwickelter Software.

Bei dem Key- & Secrets-Escrow geht es um die Hinterlegung von:

• Master‑Keys

• Zertifikats-Backups

• HSM‑Recovery‑Informationen

Wichtig sind eine strenge Zugriffskontrolle, Vier‑Augen‑Prinzip und Logging.

Das Cloud- & SaaS-Escrow denen in der modernen IT-Welt folgende Themen ab:

• API‑Skripte

• Infrastructure‑as‑Code

• Datenexportmechanismen

• Tenant‑Recovery‑Informationen

Das Ziel ist die Exit‑ und Wiederanlauf‑Fähigkeit bei SaaS‑Ausfall! Wichtig sind die Auslösebedingungen (Release Conditions). Denn aus ISMS‑Sicht müssen diese klar, überprüfbar und revisionssicher definiert sein, z. B.:

• Insolvenz / Geschäftseinstellung des Anbieters

• Nachhaltige Nichterfüllung von SLAs

• Vertragsbruch

• Sicherheitsvorfälle mit dauerhaften Auswirkungen

• Kontrollverlust über Schlüssel oder Systeme

Hohe Sicherheitsanforderungen an den Escrow-Anbieter sind die Folge, ein Escrow-Anbieter wird selbst Teil der (Notfall-) Lieferkette und muss daher Anforderungen erfüllen:

• Nachweis eines eigenen ISMS (z. B. ISO 27001)

• Physische und logische Zugriffskontrollen

• Verschlüsselung ruhender und übertragener Daten

• Mandantentrennung

• Regelmäßige Audits und Reports

• Klare Regelungen zur Datenlöschung

Aus ISMS‑Sicht ist der Escrow‑Provider daher ein kritischer Drittanbieter.

Organisatorische Einbettung im ISMS

Der Treuhänder (oben) bekommt das Objekt vom Verkäufer und bewahrt das Objekt (Code links, Dokumentationen rechts) sicher auf.

Er gibt es nur unter gewissen vertraglich festgelegten Bedingungen an den Vertragspartner.

Die sichere Aufbewahrung erfolgt über mehrere Wege, darunter onsite, in der Cloud oder in multiplen Clouds mit gesicherten und kontrollierten Verbindungen.

Der Escrow-Service sollte dokumentiert sein in:

• Risikoanalyse und ‑behandlung

• Lieferantenbewertung

• Notfall‑ und Wiederanlaufplänen

• Vertragsmanagement

• Informationsklassifizierung

• Zugriffskonzepten

Und dabei ist festzulegen:

• Was wird hinterlegt

• Wie oft aktualisiert

• Wer Zugriff erhält (oder wer der Vereter ist)

• Wie der operative Übergang erfolgt

Grenzen und Risiken von Escrow

Escrow ersetzt keine saubere Architektur, keine Dokumentation, keine Exit‑Strategie, keine regelmäßigen Backups und vor allem keine Business‑Continuity‑Planung. Zusätzliche Risiken sind Cyber-Attacken bei dem Escrow – Dienstleister, veraltete Hinterlegungen, unvollständige Artefakte und juristisch unwirksame Auslösebedingungen.

Escrow und der CRA

Der Cyber Resilience Act schafft erstmals verbindliche Cybersicherheits‑Pflichten für Produkte mit digitalen Elementen über den gesamten Produktlebenszyklus hinweg. Zentrale Pflichten für Hersteller (und mittelbar für Betreiber/Kunden) sind u. a.:

• Security‑by‑Design & Secure‑by‑Default

• Risikobasierte Produktabsicherung

• Vulnerabilitäts‑ und Patch‑Management über definierte Supportzeiträume

• Technische Dokumentation und Nachweisfähigkeit

Zentrales CRA‑Problem ist die Abhängigkeit vom Hersteller, der CRA geht implizit davon aus, dass der Hersteller verfügbar bleibt, Sicherheitsupdates liefern kann, Schwachstellen managen kann und Support über Jahre sicherstellt.

In der Praxis ist das ein strukturelles Risiko, denn CRA‑Pflichten bestehen auch dann fort, wenn:

• ein Hersteller insolvent wird,

• ein Produkt abgekündigt wird,

• ein Anbieter den Markt verlässt,

• Lieferketten zusammenbrechen.

Escrow adressiert genau diese regulatorische Lücke, kann aber nicht alles an Problemen schultern.

Wie Escrow konkret bei der CRA‑Compliance hilft

Sicherstellung der Lifecycle‑Pflichten durch den Hersteller

• Behebung von Schwachstellen

• Bereitstellung von Sicherheitsupdates

• Aufrechterhaltung der Produktsicherheit über den Supportzeitraum

Escrow ermöglicht im Ausfallfall:

• Zugriff auf Quellcode, Build‑Umgebungen, Signierschlüssel

• Fortführung von Vulnerability‑Management und Patch‑Erstellung

• Technische Fähigkeit, CRA‑Pflichten eigenständig oder mit Dritten weiter zu erfüllen

Escrow wirkt hier als technische Versicherung für gesetzliche Supportpflichten.

Nachweisfähigkeit & technische Dokumentation

Der CRA verlangt jederzeit verfügbare:

• technische Dokumentation

• Sicherheitsarchitektur

• Risikoanalysen

• Update‑ und Versionshistorien

Ein professioneller Escrow‑Service versioniert und verifiziert Artefakte, dokumentiert Update‑Zyklen und hält audittaugliche Historien vor, Escrow unterstützt daher die Beweislastumkehr zugunsten des Herstellers/Betreibers bei Marktaufsicht oder Audits.

Lieferketten‑ & Drittanbieter‑Risiko

Der CRA weitet die Verantwortung explizit auf:

• Software‑Komponenten

• Unterauftragnehmer

• eingebettete Bibliotheken aus

  
  

Escrow kann hier enthalten:

• Drittkomponenten‑Quellcodes

• SBOM‑Artefakte

• Abhängigkeitshistorien

• eigene Fork‑Stände sicherheitskritischer OSS

Damit wird praktische Kontrolle über die Lieferkette ermöglicht, statt nur vertraglicher Zusicherung.

Incident‑ und Krisenfähigkeit

Bei schwerwiegenden Sicherheitsvorfällen fordert der CRA:

• schnelles Handeln

• 24‑h‑Initialmeldung

• nachhaltige Abhilfemaßnahmen

Escrow ermöglicht:

• forensische Analysen

• Wiederherstellung und Not‑Patching ohne Hersteller

• Break‑Glass‑Zugriff auf kritische Artefakte

Escrow erhöht die operationale Reaktionsfähigkeit unter regulatorischem Zeitdruck. Aber Vorsicht, der Begriff „Break Glass“ kommt sinngemäß aus dem „Glas einschlagen“-Prinzip: Der Zugriff ist für den Notfall reserviert und soll im Normalbetrieb nicht verwendet werden. Wichtig ist dabei die Trennung zwischen normalem Betrieb und Notfallbetrieb: Break-Glass-Zugriff ist hochprivilegiert, stark geschützt und meist nur mit besonderer Genehmigung erlaubt. Er sollte nicht zur Hintertür für einen „Superadmin“ werden.

Bedeutung für Betreiber und Kunden (nicht nur Hersteller)

Auch wenn der CRA primär Hersteller adressiert, haben Betreiber und Großeinkäufer ein eigenes Risiko:

• Produkte dürfen bei Verstößen vom Markt genommen werden

• Sicherheitsupdates könnten ausbleiben

• Betriebsverbote drohen

Deshalb wird Escrow zunehmend eingesetzt als:

• Einkaufsvoraussetzung

• Exit‑ und Continuity‑Maßnahme

• Absicherung von CRA‑kritischen Produkten

Escrow wird damit faktisch ein Best Practice zur CRA‑Risikoreduktion. Was Escrow NICHT ersetzt, ist ein sicheres Design, ein aktives Vulnerability‑Management und die CRA‑Governance.

All you need: Escrow

Escrow-Services löst nicht alle Probleme, aber für konkrete Nofälle sind diese eine anerkannte, strukturierende, nachweisbare und vor allem wirksame Maßnahme zur Reduktion von Abhängigkeits‑, Verfügbarkeits‑ und Lieferkettenrisiken.

Sie sind Teil des Informationssicherheitsmanagement und unterstützen auch die Ziele des Cyber Resilience Act. Sie erhöhen die technische Handlungsfähigkeit, Auditierbarkeit und regulatorische Resilienz von Produkten mit digitalen Elementen. Natürlich sind sie – auch für den CRA - eine Hilfe, müssen aber organisiert werden und kosten Geld. Aber dafür entfaltet Escrow auch Wirkung!

Die  Insolvenz eines Software-Lieferanten OHNE hinterlegte Quellcode-Software und Handbücher ist vermutlich teurer.

Aber Vorsicht, die Escrow-Services entfalten ihren Nutzen nur bei klarer vertraglicher, technischer und organisatorischer Einbettung, sie sollten auch integriert sein in das ISMS!

Kontaktieren Sie uns!