diff --git a/adr/0014-self-service-iso-bau-orchestrierung.md b/adr/0014-self-service-iso-bau-orchestrierung.md
index b7e8d41..133e0a8 100644
--- a/adr/0014-self-service-iso-bau-orchestrierung.md
+++ b/adr/0014-self-service-iso-bau-orchestrierung.md
@@ -30,3 +30,35 @@ Der **Download läuft durch Kundenplattform hindurch gestreamt** (`GET /installa
 Ein ISO-Bau blockiert den anfragenden Request nicht, aber es gibt aktuell keine Begrenzung gleichzeitig laufender Bau-Threads — bei der aktuellen Kundenzahl kein praktisches Problem, bei deutlich mehr gleichzeitigen Bauten (mehrere Organisationen zur gleichen Zeit) müsste das nachgerüstet werden (Warteschlange oder Parallelitätslimit).
 
 Details zum technischen Payload-Mechanismus für das Mint/Casper-Backend (inklusive eines dabei gefundenen Casper-Bugs): `13-live-provisioning-boot.md`. Details zum Datenmodell (`iso_builds`): `09-data-model-v1.md`. `installationsmedium_konfiguration` (Kundenplattform-eigene Datenbank, WLAN-Zugangsdaten, gewählte Bereitstellungsvorlage) ist nicht Teil dieses provisioning-server-Datenmodells, siehe ADR-0011 zur Datenbanktrennung.
+
+## Nachtrag 26.08.2026: Zeitbasierter ISO-Ablauf nach 7 Tagen
+
+`cleanup_old_iso_builds()` (siehe oben) hat bewusst keine Zeitdimension —
+sie greift ausschließlich, wenn dieselbe Organisation erneut baut. Eine
+Organisation, die nur einmal baut und ihr Medium nie erneuert, behielt den
+Download dadurch faktisch für immer. Ergänzt (nicht ersetzt) um eine feste
+Ablauffrist: `iso_builds` bekommt eine neue Spalte `expires_at` (Migration
+`0021_iso_build_expiry.sql`), die `update_iso_build()` bei erfolgreichem
+Abschluss auf `finished_at + 7 Tage` setzt (fest ab Fertigstellung, nicht
+verlängerbar durch erneuten Download — bewusst einfach gehalten). Ein
+periodischer Sweep (`run_iso_build_expiry_sweep()`, Daemon-Thread,
+stündlich, gestartet über `@app.on_event("startup")`) löscht Datei + Zeile
+jedes `completed`-Builds mit abgelaufenem `expires_at`, unabhängig davon,
+ob die Organisation je erneut baut.
+
+Bewusst getrennt von der Enrollment-Session-Gültigkeit
+(`enrollment_sessions.expires_at`/`max_devices`, „Aufladen"-Flow oben): der
+ISO-Ablauf betrifft nur die **Downloadbarkeit der Datei**, nicht die
+Berechtigung, sich mit einer bereits verteilten ISO zu registrieren — ein
+abgelaufener Download-Link zwingt nicht zu einer neuen Registrierungsrunde
+für Geräte, die die ISO schon vor dem Ablauf heruntergeladen haben.
+
+`iso_build_row_to_dict()` und damit alle iso-builds-Endpunkte geben
+`expires_at` jetzt mit aus; Kundenplattform zeigt es auf
+`/installationsmedium` als Hinweistext beim Download-Button an.
+
+Live auf anode verifiziert: Migration eingespielt, ein Testbuild mit
+künstlich zurückdatiertem `expires_at` per SQL angelegt, Sweep-Funktion
+manuell aufgerufen (nicht die volle Stunde abgewartet) — Datei und
+Datenbankzeile wurden korrekt entfernt, ein nicht abgelaufener Build blieb
+unangetastet.