Die 24-Stunden-Uhr des CRA startet am 11. September 2026: Sorge dafür, dass jemand abnimmt

Inhaltsverzeichnis

• Was genau beginnt am 11. September 2026?
• Wer ist tatsächlich in der Pflicht?
• Warum ist eine 24-Stunden-Frist ein Alarmierungsproblem?
• Was steht eigentlich in der 24-Stunden-Frühwarnung?
• Wie stelle ich ein klingelndes Telefon vor die 24-Stunden-Uhr?
• Schritt 1 — Lege einen Anruf-Kanal nur für CRA-Kandidaten an
• Schritt 2 — Richte deine Erkennungswege auf den Kanal
• Schritt 3 — Nutze Bedingungen, damit nur plausible Kandidaten klingeln
• Schritt 4 — Fang die Systeme ab, die nur E-Mails schicken
• Schritt 5 — Nimm alle registrierten Vertreter in den Kanal auf
• Schritt 6 — Probe vor dem 11. September, nicht danach
• Was Echobell nicht leistet
• FAQ
• Macht uns Echobell CRA-konform?
• Wann startet die 24-Stunden-Uhr wirklich?
• Wir sind ein kleines Unternehmen. Sind wir befreit?
• Unser Security-Postfach wird zu Bürozeiten betreut. Reicht das nicht?
• Können Compliance, Recht und Engineering denselben Alarm bekommen?
• Hilft das bei der Nutzerinformationspflicht aus Artikel 14(8)?
• Wir melden bereits nach NIS2 oder DORA. Ist das dasselbe?
• Kommt der Anruf wirklich durch „Nicht stören“?
• Gilt das nur für iOS?
• Was gehört in den Webhook-Payload?
• Weiterlesen

Am 11. September 2026 beginnen die Meldepflichten des EU Cyber Resilience Act (CRA) zu gelten. Ab diesem Datum hat ein Hersteller, der von einer aktiv ausgenutzten Schwachstelle in einem Produkt mit digitalen Elementen — oder von einem schwerwiegenden Sicherheitsvorfall, der ein solches Produkt betrifft — Kenntnis erlangt, 24 Stunden Zeit, eine Frühwarnung an sein koordinierendes CSIRT und an die ENISA zu senden (Europäische Kommission, Verordnung (EU) 2024/2847).

Diese Frist hat eine Eigenschaft, die den meisten Compliance-Fristen fehlt: Sie läuft in echten Stunden. Keine Werktagsregel, keine Wochenendpause, keine Kulanz, während die für Meldungen zuständige Person im Flugzeug sitzt. Und die Plattform, über die eingereicht wird — die Single Reporting Platform (SRP) der ENISA —, ist ein Webformular: „In dieser Phase werden keine Programmierschnittstellen bereitgestellt“ (ENISA-FAQ). Eine namentlich benannte Person muss sich anmelden und absenden.

Damit ist die 24-Stunden-Regel zuerst ein Alarmierungsproblem und erst danach ein Papierproblem. Dieser Leitfaden zeigt, wie du den Moment der Kenntniserlangung mit Echobell in ein klingelndes Telefon überführst — und benennt ehrlich den großen Teil der CRA-Vorbereitung, den kein Benachrichtigungswerkzeug berührt.

Was genau beginnt am 11. September 2026?

Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über eine einzige EU-Plattform melden, auf einer gestaffelten Uhr, die im Moment der Kenntniserlangung startet. Alles Übrige im CRA — CE-Kennzeichnung, die grundlegenden Anforderungen in Anhang I, Konformitätsbewertung — gilt ab dem 11. Dezember 2027. Die Meldepflicht kommt fünfzehn Monate früher, und sie betrifft auch Produkte, die bereits auf dem Markt sind, nicht nur das, was du nach dem Stichtag auslieferst (cyberresilienceact.eu).

Artikel 14 definiert zwei parallele Stränge mit derselben Form:

Der Wortlaut ist „unverzüglich und in jedem Fall innerhalb von 24 Stunden, nachdem der Hersteller davon Kenntnis erlangt hat“ (Artikel 14). Vierundzwanzig Stunden sind die Obergrenze, nicht das Ziel.

Artikel 14(5) setzt die Schwelle für „schwerwiegend“: Ein Vorfall ist es, wenn er die Fähigkeit des Produkts, die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit sensibler oder wichtiger Daten oder Funktionen zu schützen, beeinträchtigt oder beeinträchtigen kann, oder wenn er zur Einschleusung oder Ausführung von Schadcode geführt hat oder führen kann. Dieses „kann“ ist entscheidend: Eine Meldepflicht kann bestehen, bevor bei einem Kunden tatsächlich etwas schiefgegangen ist.

Artikel 14(8) fügt eine zweite, parallel laufende Pflicht hinzu: Du musst auch die betroffenen Nutzer des Produkts über die Schwachstelle oder den Vorfall informieren und, soweit erforderlich, über Korrekturmaßnahmen, die sie ergreifen können. Das ist ein anderer Adressat als das CSIRT, auf einem eigenen Weg.

Wer ist tatsächlich in der Pflicht?

Hersteller von Produkten mit digitalen Elementen, unabhängig vom Sitz — dazu Open-Source-Software-Verwalter (Stewards) in engerem Umfang. Ein Unternehmen außerhalb der EU, das in die Union verkauft, entkommt der Pflicht nicht; die Verordnung erwartet, dass ein Wirtschaftsakteur in der EU für die einschlägigen Pflichten verantwortlich ist (cyberresilienceact.eu).

Gemeldet wird an das als Koordinator benannte CSIRT des Mitgliedstaats, in dem du deine Hauptniederlassung in der Union hast, und gleichzeitig an die ENISA — eingereicht wird aber nur einmal, über die Single Reporting Platform, die an beide weiterleitet (Europäische Kommission).

Open-Source-Software-Verwalter fallen unter eine klar begrenzte Teilmenge: Die Pflicht aus Artikel 14(1) gilt, soweit sie an der Entwicklung von Produkten mit digitalen Elementen beteiligt sind, und Artikel 14(3) und (8) gelten, soweit schwerwiegende Vorfälle die Netz- und Informationssysteme betreffen, die sie für diese Entwicklung bereitstellen. Wer ein weit verbreitetes Projekt verwaltet, sollte Artikel 24 zusammen mit Artikel 14 lesen, statt eines der beiden Extreme anzunehmen.

Artikel 15 erlaubt zusätzlich freiwillige Meldungen — zu Schwachstellen, Cyberbedrohungen, Vorfällen und Beinaheereignissen — durch Hersteller und beliebige andere Personen. Freiwillige Meldungen begründen keine neuen Pflichten, laufen aber über dieselbe Plattform und haben dasselbe Problem: Jemand muss wach sein.

Warum ist eine 24-Stunden-Frist ein Alarmierungsproblem?

Weil die Uhr mit der Kenntniserlangung startet und Kenntnis selten während der Bürozeiten eintrifft. Der Auslöser ist eine Tatsache, die deine Organisation erreicht — nicht eine Entscheidung, die sie trifft.

Schau, woher diese Tatsache typischerweise kommt. Ein Sicherheitsforscher schreibt samstags um 23:40 Uhr an security@. Ein nachgelagerter Kunde eröffnet ein Ticket, das eine Ausnutzung beschreibt. Ein CVE- oder KEV-Feed schlägt zu einer Komponente an, die du auslieferst. Dein eigenes EDR meldet Codeausführung in einem Build-System. Die Readiness-Analyse von DLA Piper benennt die Lieferketten-Variante davon ausdrücklich: Hersteller erfahren es oft nicht zuerst, und Informationen kommen über Importeure, Händler, Forscher oder Komponentenlieferanten (DLA Piper).

Jeder dieser Wege endet in einer Benachrichtigung, die dein heutiges Setup vermutlich lautlos zustellt: eine E-Mail in einem geteilten Postfach, eine Nachricht in einem Slack-Kanal, den nachts niemand liest, ein Ticket in einer Warteschlange, die montags triagiert wird. Keine davon schlägt fehl. Alle werden korrekt zugestellt — an niemanden.

Drei Details machen die Lücke größer, als sie aussieht:

• Es gibt keine API. Die ENISA stellt klar, dass in dieser Phase keine Melde-APIs bereitgestellt werden. Du kannst kein Skript die Frühwarnung einreichen lassen, während alle schlafen.
• Der Zugang wird personenbezogen und im Voraus eingerichtet. Bevollmächtigte Vertreter registrieren sich mit einem EU-Login-Konto, und das benannte koordinierende CSIRT bestätigt ihre Berechtigung nach dem ersten Zugriff. Es gibt einen primären Vertreter und einen Stellvertreter, und die Einladung an den Stellvertreter verfällt nach sieben Tagen (ENISA-FAQ, cyberresilienceact.eu). Ist die einzige einreichungsberechtigte Person nicht erreichbar, interessiert das die Frist nicht.
• Die Bußgeldstufe ist die hohe. Artikel 64 ordnet Verstöße gegen die Pflichten aus Artikel 13 und 14 der Stufe von Geldbußen „bis zu 15 000 000 EUR oder, im Falle eines Unternehmens, bis zu 2,5 % des gesamten weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem, welcher Betrag höher ist“ zu (Artikel 64).

Eine ehrliche Einschränkung zum letzten Punkt, weil sie die Rechnung für kleine Teams verändert: Artikel 64 nimmt Hersteller, die Kleinstunternehmen oder kleine Unternehmen sind, von Geldbußen wegen Versäumens der Frist in Artikel 14(2)(a) oder 14(4)(a) aus — also genau der 24-Stunden-Frühwarnung. Die Meldepflicht selbst bleibt bestehen, und die Ausnahme erstreckt sich weder auf die 72-Stunden-Meldung noch auf den Rest von Artikel 14. Lies den Artikel und hol dir Rat, statt einem Blogbeitrag zu glauben, wo dein Unternehmen einzuordnen ist.

Was steht eigentlich in der 24-Stunden-Frühwarnung?

Sehr wenig — und das ist der Punkt. Die ENISA-Anleitung beschreibt für die Frühwarnstufe einen kleinen Satz Pflichtfelder: Meldungsart (Schwachstelle oder Vorfall), Meldungsstufe, Meldezeitpunkt, Angaben zur meldenden Person, Name des Herstellers oder Verwalters, das Produkt, ein Titel und — bei Vorfällen — ob rechtswidrige oder böswillige Handlungen vermutet werden. Optionale Felder auf dieser Stufe sind unter anderem eine CVE-ID oder eine EUVD-ID.

Das vollständigere technische Bild — allgemeine Art der Schwachstelle oder des Exploits, eine erste Einschätzung, Korrektur- und Abhilfemaßnahmen — gehört in die 72-Stunden-Meldung, nicht in die ersten 24 Stunden.

Die Frühwarnung ist also kein Forschungsprojekt, sondern ein kurzes Formular, das eine vorbereitete Person in Minuten ausfüllt. Der begrenzende Faktor ist nicht das Formular. Es ist die Frage, ob eine registrierte, berechtigte und wache Person rechtzeitig davon erfährt. Das ist ein Problem der Benachrichtigungszustellung — und heute lösbar.

Wie stelle ich ein klingelndes Telefon vor die 24-Stunden-Uhr?

Echobell verwandelt einen Webhook-Aufruf oder eine E-Mail in einen Alarm, der wie ein eingehender Anruf klingelt und vibriert — deshalb kommt er durch den iOS-Fokus und „Nicht stören“ (siehe den iOS-Fokus umgehen). Das folgende Setup ergänzt euer bestehendes Ticket- und PSIRT-Verfahren; es ersetzt es nicht.

Schritt 1 — Lege einen Anruf-Kanal nur für CRA-Kandidaten an

Erstelle in der App einen Kanal und setze den Benachrichtigungstyp auf Anruf (Benachrichtigungstypen). Benenne ihn nach der Entscheidung, die er auslöst, nicht nach der Datenquelle: „CRA — 24-h-Uhr läuft möglicherweise“ ist besser als „Security-Alarme“.

Dieser Kanal muss leise bleiben. Klingelt er bei jedem Advisory, jedem fehlgeschlagenen Scan und jedem Dependency-Update, nehmen die Leute nicht mehr ab — und du hast deinen einzigen lauten Kanal für Rauschen verbraucht. Leite das woandershin; der Leitfaden zur Alarmmüdigkeit beschreibt die Aufteilung.

Kopiere die Webhook-URL aus den Kanaldetails; sie sieht aus wie https://hook.echobell.one/t/<channel-token>. Behandle sie als Geheimnis, denn wer sie hat, kann die Telefone deines Teams klingeln lassen (Webhook-Leitfaden).

Lege Vorlagen fest, die um 02:00 Uhr halb wach auf einem Sperrbildschirm lesbar sind:

Titel: Mögliche CRA-Meldung — {{product}}
Text: {{kind}} — {{summary}} (bekannt seit {{time}} UTC)

{{time}}, {{date}}, {{hour}} und die übrigen System-Zeitvariablen werden immer in UTC eingesetzt, sodass die Benachrichtigung einen Zeitstempel trägt, auch wenn der Absender keinen mitschickt. Dieser Zeitstempel ist kein juristischer Beleg dafür, wann die Kenntnis begann, aber ein nützlicher Anker, wenn du später die Chronologie rekonstruierst.

Schritt 2 — Richte deine Erkennungswege auf den Kanal

Jedes System, das einen Webhook aufrufen kann, kann den Kanal auslösen. Gesendete Felder werden zu Vorlagenvariablen:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "aktiv ausgenutzte Schwachstelle",
    "summary": "Forscherbericht, funktionierender Exploit beigefügt",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'

Die Spezialvariable externalLink wird im Benachrichtigungsverlauf zu einem klickbaren Link, sodass die Person nach dem Abnehmen einen Fingertipp vom Ticket mit den Details entfernt ist.

Lohnenswert anzubinden, grob nach Häufigkeit als Erstsignal:

• Eure PSIRT- oder Security-Eingangswarteschlange — ein Webhook, sobald ein Vorgang als CRA-Kandidat markiert wird.
• GitHub Security Advisories und Dependabot-Alarme in Repositories, die ausgelieferte Produkte bauen (GitHub-Integration).
• Euer SIEM, EDR oder WAF, für Erkennungen gegen Build-, Release- oder Signatur-Infrastruktur — Artikel 14(5) erfasst ausdrücklich Vorfälle, die zur Einschleusung von Schadcode führen können.
• Schwachstellen-Feeds, die ihr ohnehin bezieht, gefiltert auf Komponenten aus euren eigenen SBOMs.

Schritt 3 — Nutze Bedingungen, damit nur plausible Kandidaten klingeln

Dieser Schritt entscheidet, ob der Kanal glaubwürdig bleibt. Echobell-Bedingungen werten dieselben Variablen und HTTP-Header aus wie deine Vorlagen, und der Kanal löst nur aus, wenn der Ausdruck wahr ist:

craCandidate == true && confirmed == true

Oder filtere über einen Header, wenn das sendende System den Body nicht formen kann:

header["x-cra-severity"] == "reportable"

Setze die Schwelle auf „eine fachkundige Person sollte sich das innerhalb einer Stunde ansehen“, nicht auf „das ist sicher meldepflichtig“. Ob Artikel 14 greift, ist eine Bewertung, die einen Menschen mit den Fakten erfordert; die Aufgabe des Kanals ist es, diesen Menschen schnell zu den Fakten zu bringen. Zu scharf zu filtern ist hier der teure Fehler, denn eine nie begonnene Meldung ist schlimmer als ein Anruf, den du nicht gebraucht hättest.

Schritt 4 — Fang die Systeme ab, die nur E-Mails schicken

Der erste Kontakt von außen kommt meist per E-Mail: der Forscher, der Kunde, das nationale CSIRT, der Komponentenlieferant. Jeder Echobell-Kanal kann eine eigene Adresse haben, sodass eine einzige Weiterleitungsregel auf security@ diese Nachrichten in Anrufe verwandelt (E-Mail-Auslöser).

E-Mail-Auslöser stellen from, to, subject, text und html als Variablen bereit, du kannst also ohne Parsen filtern:

subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")

Vereinbare mit euren regelmäßigen Meldern und wichtigen Lieferanten eine Betreff-Markierung und filtere darauf. Ein kleines vertragliches Detail, das aus einem unstrukturierten Postfach ein routbares Signal macht.

Schritt 5 — Nimm alle registrierten Vertreter in den Kanal auf

Teile den Kanal mit allen, die tatsächlich einreichen können: dem primären bevollmächtigten Vertreter, dem Stellvertreter und der Sicherheitsverantwortlichen, die die Artikel-14-Entscheidung treffen kann. Jede abonnierende Person wählt ihren eigenen Benachrichtigungstyp, sodass die diensthabende Person auf Anruf stehen kann und der Rest auf Zeitkritisch.

Genau darum geht es. Die SRP verlangt eine registrierte, validierte natürliche Person. Ist im Unternehmen nur eine Person registriert, hat deine 24-Stunden-Frist einen Single Point of Failure mit Handyakku.

Schritt 6 — Probe vor dem 11. September, nicht danach

Zwei Proben, beide diesen Monat sinnvoll:

1. Der Alarmweg. Feuere das obige curl bei tatsächlich aktivem „Nicht stören“ ab, auf dem Telefon, das wirklich auf dem Nachttisch liegen wird. Aktiviere in der App Fehlgeschlagene Anrufe wiederholen, damit ein einmal gescheiterter Anruf erneut versucht wird. Ein ungetesteter Eskalationsweg ist eine Annahme.
2. Der Einreichungsweg. Geh eine Meldung auf dem Papier durch, anhand der Schritt-für-Schritt-Anleitungen der ENISA zu Registrierung und Einreichung, die bis in den August 2026 hinein aktualisiert wurden (ENISA SRP). Legt die EU-Login-Konten jetzt an, klärt, welches CSIRT euer Koordinator ist, und verschickt die Einladung an den Stellvertreter früh — sie verfällt nach sieben Tagen.

Die zweite Probe hat einen Haken, den man kennen sollte: Nach dem Stand der ENISA-Anleitung von Juli war die öffentliche URL der Plattform noch als „wird zum Start bereitgestellt“ ausgewiesen, ein echter Ende-zu-Ende-Test war also nicht möglich (cyberresilienceact.eu). Die ENISA hat zugesagt, dass die Plattform bis zum 11. September 2026 betriebsbereit ist. Probe alles, was in deiner Hand liegt, und mach die Bereitschaft der Plattform nicht zum Grund, deine eigene aufzuschieben.

Was Echobell nicht leistet

Hier präzise zu sein ist wichtiger als sonst, weil das Thema regulatorisch ist:

• Es macht dich nicht konform. Echobell ist ein Benachrichtigungskanal. Produkte zu erfassen, einen Schwachstellenprozess zu betreiben, zu entscheiden, ob Artikel 14 greift, sich bei der SRP zu registrieren und fristgerecht einzureichen — das alles bleibt bei dir. Kein Alarmierungswerkzeug hat je eine Meldepflicht erfüllt.
• Es reicht nichts ein. Es gibt keine API zum Einreichen, und selbst wenn es sie gäbe, wäre Echobell nicht das, was sie aufruft. Es lässt ein Telefon klingeln; den Rest erledigt ein registrierter Mensch.
• Es ist kein juristischer Zeitstempel. Die Variable {{time}} hält fest, wann der Auslöser Echobell erreicht hat, in UTC. Wann die „Kenntniserlangung“ begann, ist eine Tatsachenfrage über deine Organisation, und dokumentiert wird sie durch eure Vorfallakte, nicht durch eine Push-Benachrichtigung.
• Es hat keine Eskalationsrichtlinien und keine Quittierung. Es gibt kein „wenn in zehn Minuten niemand abnimmt, ruf die nächste Person an“, keine Rotation, keinen Prüfpfad, wer was bestätigt hat. Dafür braucht es eine Incident-Plattform — siehe Opsgenie-Alternativen.
• Es kann Zustellung nicht garantieren. Ein Anruf hängt an Push-Infrastruktur, Netz und einem geladenen Telefon. Betrachte es als die Schicht, die den Abstand zwischen einer eintreffenden Tatsache und einem informierten Menschen verkürzt — nicht als Kontrolle, auf die du im Audit zeigst.
• Es kennt keine Lokalzeit. Die eingebauten Zeitvariablen sind ausschließlich UTC und folgen keiner Sommerzeit. Bedingungen mit Zeitfenstern brauchen zweimal im Jahr eine manuelle Anpassung.

FAQ

Macht uns Echobell CRA-konform?

Nein. Der CRA legt Herstellern Pflichten auf, und keine Benachrichtigungs-App kann sie erfüllen. Echobell adressiert einen konkreten Fehlerfall: Die 24-Stunden-Frühwarnung wird verpasst, weil die Person, die sie hätte einreichen können, erst am nächsten Arbeitstag davon erfuhr. Dieser Fehlerfall ist real und häufig — aber er ist ein Teil eines viel größeren Compliance-Programms.

Wann startet die 24-Stunden-Uhr wirklich?

Wenn der Hersteller Kenntnis von der aktiv ausgenutzten Schwachstelle oder dem schwerwiegenden Vorfall erlangt. Die Verordnung definiert keinen exakten Moment; Kenntnis hängt von den Tatsachen ab und davon, wie schnell sie feststellbar sind (DLA Piper). Praktisch spricht das für schnelle und dokumentierte Triage: Je größer der Abstand zwischen eintreffendem Signal und Bewertung, desto schwerer ist er später zu erklären.

Wir sind ein kleines Unternehmen. Sind wir befreit?

Von der Meldung nicht. Artikel 64 nimmt Kleinstunternehmen und kleine Unternehmen von Geldbußen aus, und zwar speziell für das Versäumen der 24-Stunden-Frist aus Artikel 14(2)(a) oder 14(4)(a). Die Meldepflicht bleibt, die 72-Stunden-Meldung und der Abschlussbericht sind unberührt, und die Definitionen von Kleinst- und kleinem Unternehmen sind nichts, was man einfach annimmt. Behandle es als enge Milderung, nicht als Freifahrtschein.

Unser Security-Postfach wird zu Bürozeiten betreut. Reicht das nicht?

Nur wenn du bereit bist, an einem normalen Wochenende bis zu zwei Drittel des Zeitfensters zu verlieren. Eine Meldung, die freitags um 18:00 Uhr eintrifft, hat eine Frist bis Samstag 18:00 Uhr. Überwachung zu Bürozeiten ist für fast alles andere eine vernünftige Voreinstellung; die 24-Stunden-Uhr ist genau der Fall, den sie nicht abdeckt.

Können Compliance, Recht und Engineering denselben Alarm bekommen?

Ja, und sie sollten. Teilt einen Kanal, und jede abonnierende Person wird beim selben Auslöser benachrichtigt — mit selbst gewählter Dringlichkeit. Die Person, die die Ausnutzung bestätigt, und die Person, die das Formular absendet, müssen in derselben Minute anfangen, nicht nacheinander.

Hilft das bei der Nutzerinformationspflicht aus Artikel 14(8)?

Indirekt. Artikel 14(8) verlangt, betroffene Nutzer über die Schwachstelle oder den Vorfall und, soweit erforderlich, über Korrekturmaßnahmen zu informieren. Das ist Kundenkommunikation und braucht eure eigenen Kanäle. Echobell kann die Personen, die diese Kommunikation verantworten, zeitgleich mit denen wecken, die die Einreichung verantworten, sodass beide Stränge gemeinsam starten.

Wir melden bereits nach NIS2 oder DORA. Ist das dasselbe?

Nein, auch wenn sich die Formen ähneln. NIS2 und DORA legen Einrichtungen Pflichten nach Sektor und Kritikalität auf; der CRA legt Herstellern Pflichten nach den Produkten auf, die sie auf dem EU-Markt bereitstellen. Eine Organisation kann allen dreien unterliegen — mit unterschiedlichen Uhren und Adressaten. Wenn diese Regime für euch ebenfalls gelten, siehe DORA- und NIS2-Meldealarme; die Alarmierungsschicht lässt sich teilen, auch wenn die Pflichten es nicht tun.

Kommt der Anruf wirklich durch „Nicht stören“?

Anruf-Benachrichtigungen werden als anrufartige Alarme zugestellt, und genau das lässt sie den Fokus auf iOS durchbrechen. Magie ist es nicht: Es hängt weiterhin an Systemeinstellungen, Netz und einem geladenen Telefon. Teste es auf dem echten Gerät, mit tatsächlich aktivem Fokus, bevor du dich darauf verlässt — und aktiviere Fehlgeschlagene Anrufe wiederholen.

Gilt das nur für iOS?

Nein. Echobell gibt es für iOS und für Android über Google Play (Android-Release). Das Verhalten anrufartiger Alarme unterscheidet sich zwischen den Plattformen — teste auf dem Gerät, das die diensthabende Person tatsächlich bei sich trägt.

Was gehört in den Webhook-Payload?

Das Minimum, um zu entscheiden, ob man aufsteht: das Produkt, die Art des Signals, eine Zeile Kontext und ein externalLink auf das Ticket mit den Details. Echobell speichert Benachrichtigungsinhalte und -verlauf auf dem Gerät und serverseitig nur Konten, Kanäle und Abonnements (Datenschutzmodell) — die richtige Gewohnheit bei sicherheitsrelevantem Material bleibt dennoch, einen Zeiger zu senden, nicht den Inhalt.

---

Weiterlesen

• DORA- und NIS2-Meldealarme
• Alarmmüdigkeit in den Griff bekommen
• Wie du den iOS-Fokus für kritische Alarme umgehst
• Alternativen nach dem Opsgenie-Aus
• Webhook-Integrationsleitfaden
• E-Mail-Auslöser
• Leitfaden zu Bedingungen