CRA'nın 24 Saatlik Sayacı 11 Eylül 2026'da Başlıyor: Birinin Yanıt Verdiğinden Emin Olun

İçindekiler

11 Eylül 2026'da tam olarak ne başlıyor?
Sorumluluk gerçekte kimde?
24 saatlik son tarih neden bir uyarı sorunu?
24 saatlik erken uyarı gerçekte neyi içeriyor?
24 saatlik sayacın önüne nasıl çalan bir telefon koyarım?
Adım 1 — CRA adaylarına ayrılmış bir Arama kanalı oluşturun
Adım 2 — Tespit yollarınızı kanala yönlendirin
Adım 3 — Yalnızca makul adayların çalması için koşulları kullanın
Adım 4 — Yalnızca e-posta gönderen sistemleri yakalayın
Adım 5 — Kayıtlı her temsilciyi kanala ekleyin
Adım 6 — 11 Eylül'den sonra değil, önce prova edin
Echobell'in yapmadıkları
SSS
Echobell kullanmak bizi CRA uyumlu yapar mı?
24 saatlik sayaç gerçekte ne zaman başlar?
Küçük bir şirketiz. Muaf mıyız?
Güvenlik gelen kutumuz mesai saatlerinde izleniyor. Bu yetmez mi?
Uyum, hukuk ve mühendislik aynı uyarıyı alabilir mi?
Bu, Madde 14(8)'deki kullanıcıları bilgilendirme yükümlülüğüne yardımcı olur mu?
Zaten NIS2 veya DORA kapsamında bildirim yapıyoruz. Bu aynı şey mi?
Arama gerçekten Rahatsız Etmeyin modunu aşar mı?
Bu yalnızca iOS'ta mı var?
Webhook yüküne ne koymalıyız?
İlgili içerikler

11 Eylül 2026'da AB Siber Dayanıklılık Yasası'nın raporlama yükümlülükleri yürürlüğe giriyor. Bu tarihten itibaren, dijital öğeler içeren bir üründe aktif olarak istismar edilen bir zafiyetten — ya da bunu etkileyen ciddi bir olaydan — haberdar olan bir üreticinin, koordinatör CSIRT'ine ve ENISA'ya erken uyarı göndermek için 24 saati var (Avrupa Komisyonu, (AB) 2024/2847 sayılı Tüzük).

Bu son tarihin çoğu uyum son tarihinde bulunmayan bir özelliği var: duvar saatiyle işliyor. İş günü istisnası yok, hafta sonu duraklaması yok ve raporlama sorumlunuz uçaktayken tanınan bir ek süre yok. Bildirimi göndereceğiniz platform, ENISA'nın Tek Raporlama Platformu ise bir web formu — "bu aşamada herhangi bir Uygulama Programlama Arayüzü sağlanmayacaktır" (ENISA SSS). Adı belli bir insanın oturum açıp göndermesi gerekiyor.

Bu da 24 saat kuralını, bir evrak sorunu olmadan önce bir uyarı sorunu hâline getiriyor. Bu rehber, haberdar olma anını Echobell ile çalan bir telefona nasıl yönlendireceğinizi gösteriyor ve CRA hazırlığının hiçbir bildirim aracının dokunamayacağı büyük kısmı konusunda dürüst davranıyor.

11 Eylül 2026'da tam olarak ne başlıyor?

Dijital öğeler içeren ürünlerin üreticileri, aktif olarak istismar edilen zafiyetleri ve ciddi olayları, haberdar oldukları andan itibaren işleyen kademeli bir sayaçla tek bir AB platformu üzerinden bildirmek zorunda. CRA'daki diğer her şey — CE işareti, Ek I'deki temel gereklilikler, uygunluk değerlendirmesi — 11 Aralık 2027'den itibaren geçerli. Raporlama on beş ay önce geliyor ve yalnızca bu tarihten sonra piyasaya sürdüklerinize değil, hâlihazırda piyasada olan ürünlere de uygulanıyor (cyberresilienceact.eu).

Madde 14, aynı biçime sahip iki paralel yol tanımlıyor:

Aşama	Aktif olarak istismar edilen zafiyet — Mad. 14(2)	Ciddi olay — Mad. 14(4)
Erken uyarı	Haberdar olduktan sonra 24 saat içinde	Haberdar olduktan sonra 24 saat içinde
Bildirim	Haberdar olduktan sonra 72 saat içinde	Haberdar olduktan sonra 72 saat içinde
Nihai rapor	Düzeltici ya da hafifletici bir önlem hazır olduktan en geç 14 gün sonra	72 saatlik bildirimden sonra bir ay içinde

İfade şöyle: "gereksiz gecikme olmaksızın ve her hâlükârda üreticinin haberdar olmasından itibaren 24 saat içinde" (Madde 14). Yirmi dört saat üst sınırdır, hedef değil.

Madde 14(5) "ciddi" eşiğini belirliyor: bir olay, ürünün hassas veya önemli veri ya da işlevlerin erişilebilirliğini, gerçekliğini, bütünlüğünü veya gizliliğini koruma yeteneğini olumsuz etkiliyorsa ya da etkileyebilecek durumdaysa, veya kötü amaçlı kodun eklenmesine ya da çalıştırılmasına yol açtıysa veya açabilecek durumdaysa bu tanıma girer. "Edebilecek durumda" ifadesi önemli — bir müşteri açısından henüz gerçekten bir şey ters gitmeden rapor borcunuz doğabilir.

Madde 14(8), paralel işleyen ikinci bir yükümlülük ekliyor: ürünün etkilenen kullanıcılarını da zafiyet veya olay hakkında ve gerektiğinde alabilecekleri düzeltici önlemler konusunda bilgilendirmeniz gerekiyor. Bu, CSIRT'ten ayrı bir muhatap kitlesi ve kendi yolu var.

Sorumluluk gerçekte kimde?

Nerede kurulu olurlarsa olsunlar, dijital öğeler içeren ürünlerin üreticilerinde; ayrıca daha dar bir biçimde açık kaynak yazılım yöneticilerinde. AB dışındaki bir şirket Birliğe satış yapıyorsa bu yükümlülükten kaçamaz; tüzük, ilgili yükümlülüklerden sorumlu olacak bir ekonomik operatörün AB'de bulunmasını bekler (cyberresilienceact.eu).

Bildirimi, Birlik'teki ana kuruluşunuzun bulunduğu Üye Devlette koordinatör olarak belirlenen CSIRT'e ve eş zamanlı olarak ENISA'ya yaparsınız — ancak bir kez, Tek Raporlama Platformu üzerinden gönderirsiniz; platform bildirimi her ikisine de iletir (Avrupa Komisyonu).

Açık kaynak yazılım yöneticileri tanımlı bir alt küme için kapsamdadır: Madde 14(1) yükümlülüğü, dijital öğeler içeren ürünlerin geliştirilmesine dahil oldukları ölçüde geçerlidir; Madde 14(3) ve (8) ise ciddi olayların, bu geliştirme için sağladıkları ağ ve bilgi sistemlerini etkilediği ölçüde geçerlidir. Yaygın kullanılan bir projeyi yönetiyorsanız, uçlardan birini varsaymak yerine Madde 24'ü Madde 14 ile birlikte okuyun.

Madde 15 ayrıca gönüllü bildirime izin veriyor — zafiyetler, siber tehditler, olaylar ve ramak kalalar için — hem üreticiler hem de başka herkes tarafından. Gönüllü bildirimler yeni yükümlülük doğurmaz, ancak aynı platform ve aynı "birinin uyanık olması gerekiyor" sorunu geçerlidir.

24 saatlik son tarih neden bir uyarı sorunu?

Çünkü sayaç siz haberdar olduğunuzda başlar ve haberdar olmak nadiren mesai saatlerinde gerçekleşir. Tetikleyici, kuruluşunuzun verdiği bir karar değil, kuruluşunuza ulaşan bir olgudur.

Bu olgunun genellikle nereden geldiğine bakın. Bir güvenlik araştırmacısı cumartesi 23.40'ta security@ adresine e-posta atar. Alt taraftaki bir müşteri, istismarı anlatan bir destek talebi açar. Sevk ettiğiniz bir bileşen için bir CVE ya da KEV akışı alarm verir. Kendi EDR'niz bir derleme sisteminde kod çalıştırıldığını işaretler. DLA Piper'ın hazırlık notu bunun özellikle tedarik zinciri sürümüne dikkat çekiyor: üreticiler çoğu zaman ilk öğrenen taraf değildir ve bilgi ithalatçılar, dağıtıcılar, araştırmacılar ya da bileşen tedarikçileri üzerinden gelir (DLA Piper).

Bu yolların her biri, mevcut kurulumunuzun muhtemelen sessizce ilettiği bir bildirimle biter — ortak bir gelen kutusundaki e-posta, gece kimsenin izlemediği bir kanaldaki Slack mesajı, pazartesi triyaj edilecek bir kuyruktaki talep. Hiçbiri başarısız olmaz. Hepsi doğru şekilde, hiç kimseye ulaşır.

Üç ayrıntı boşluğu göründüğünden daha kötü hâle getiriyor:

API yok. ENISA, bu aşamada raporlama API'si sağlanmayacağını açıkça belirtiyor. Herkes uyurken erken uyarıyı sizin yerinize gönderecek bir betiğiniz olamaz.
Erişim kişi bazlı ve önceden yapılan bir kurulum. Yetkili temsilciler bir EU Login hesabıyla kaydolur ve belirlenen koordinatör CSIRT, ilk erişimin ardından yetkilerini doğrular. Bir birincil temsilci ve bir yedek temsilci vardır; yedeğe gönderilen davetin süresi yedi gün sonra dolar (ENISA SSS, cyberresilienceact.eu). Bildirimi gönderebilecek tek kişiye ulaşılamıyorsa son tarih bunu umursamaz.
Ceza dilimi üst dilim. Madde 64, Madde 13 ve 14 yükümlülüklerine uyulmamasını "15 000 000 EUR'ya kadar veya ihlal eden bir teşebbüs ise bir önceki mali yıla ait toplam dünya çapındaki yıllık cirosunun %2,5'ine kadar, hangisi yüksekse" idari para cezası bandına koyuyor (Madde 64).

Son maddeye dair dürüst bir kayıt, çünkü küçük ekipler için hesabı değiştiriyor: Madde 64, mikro işletme veya küçük işletme sayılan üreticileri, Madde 14(2)(a) ya da 14(4)(a)'daki son tarihi kaçırmaya ilişkin idari para cezalarından muaf tutuyor — yani özellikle 24 saatlik erken uyarıdan. Bildirim yükümlülüğü yine de sürüyor ve muafiyet 72 saatlik bildirimi ya da Madde 14'ün geri kalanını kapsamıyor. Şirketinizin nereye düştüğü konusunda bir blog yazısına güvenmek yerine maddeyi okuyun ve danışmanlık alın.

24 saatlik erken uyarı gerçekte neyi içeriyor?

Çok az şey — ki mesele de bu. ENISA'nın rehberi erken uyarı aşamasında küçük bir zorunlu alan kümesi tanımlıyor: bildirim türü (zafiyet ya da olay), bildirim seviyesi, bildirim zamanı, bildiren kişi bilgileri, üretici veya yönetici adı, ürün, bir başlık ve olaylar için hukuka aykırı ya da kötü niyetli eylemlerden şüphelenilip şüphelenilmediği. Bu aşamadaki isteğe bağlı alanlar arasında bir CVE kimliği ya da EUVD kimliği yer alıyor.

Daha ayrıntılı teknik tablo — zafiyetin veya istismarın genel niteliği, bir ilk değerlendirme, düzeltici ve hafifletici önlemler — ilk 24 saate değil, 72 saatlik bildirime aittir.

Yani erken uyarı bir araştırma projesi değil. Hazırlıklı bir kişinin dakikalar içinde doldurabileceği kısa bir form. Bağlayıcı kısıt form değil. Kısıt, kayıtlı, yetkili ve uyanık bir kişinin zamanında haberdar olup olmadığıdır. Bu bir bildirim yönlendirme sorunudur ve bugün çözülebilir.

24 saatlik sayacın önüne nasıl çalan bir telefon koyarım?

Echobell, bir webhook çağrısını ya da e-postayı gelen arama gibi çalan ve titreşen bir uyarıya dönüştürür; iOS Odak Modu'nu ve Rahatsız Etmeyin'i böyle aşar (bkz. iOS Odak Modu'nu aşmak). Aşağıdaki kurulum, hâlihazırda yürüttüğünüz talep yönetimi ve PSIRT süreçlerinin yanında durur — onların yerini almaz.

Adım 1 — CRA adaylarına ayrılmış bir Arama kanalı oluşturun

Uygulamada bir kanal oluşturun ve bildirim türünü Arama olarak ayarlayın (bildirim türleri). Adını veri kaynağına göre değil, tetiklediği karara göre koyun: "CRA — 24 saatlik sayaç başlamış olabilir", "Güvenlik uyarıları"ndan daha iyidir.

Bu kanal sessiz kalmalı. Her bültende, her başarısız taramada ve her bağımlılık güncellemesinde çalarsa insanlar yanıt vermeyi bırakır ve tek gürültülü kanalınızı boşa harcamış olursunuz. Bunları başka yere yönlendirin — uyarı yorgunluğu rehberi bu ayrımı anlatıyor.

Kanalın webhook URL'sini ayrıntılarından kopyalayın; şuna benzer: https://hook.echobell.one/t/<channel-token>. Bunu bir sır gibi saklayın, çünkü elinde tutan herkes ekibinizin telefonlarını çaldırabilir (webhook rehberi).

Saat 02.00'de yarı uykulu birinin kilit ekranından okuyabileceği şablonlar tanımlayın:

Title: Possible CRA report — {{product}}
Body: {{kind}} — {{summary}} (aware since {{time}} UTC)

{{time}}, {{date}}, {{hour}} ve diğer sistem zaman değişkenleri her zaman UTC olarak eklenir; böylece gönderen unutsa bile bildirim bir zaman damgası kaydeder. Bu zaman damgası, haberdar olmanın ne zaman başladığına dair hukuki bir kanıt değildir ama zaman çizelgesini sonradan yeniden kurarken işe yarayan bir çıpadır.

Adım 2 — Tespit yollarınızı kanala yönlendirin

Webhook çağırabilen her sistem kanalı tetikleyebilir. Gönderdiğiniz alanlar şablon değişkenlerine dönüşür:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "actively exploited vulnerability",
    "summary": "researcher report, working exploit attached",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'

Özel externalLink değişkeni bildirim kaydında tıklanabilir bir bağlantıya dönüşür; böylece aramayı yanıtlayan kişi ayrıntıları tutan kayda tek dokunuş uzaklıkta olur.

Genellikle ilk sinyal olma sıklıklarına göre kabaca bağlanmaya değer kaynaklar:

PSIRT ya da güvenlik giriş kuyruğunuz — bir kayıt CRA adayı olarak etiketlendiğinde bir webhook.
Sevk edilen ürünleri derleyen depolardaki GitHub güvenlik bültenleri ve Dependabot uyarıları (GitHub entegrasyonu).
Derleme, sürüm ya da imzalama altyapısına yönelik tespitler için SIEM, EDR veya WAF'ınız — Madde 14(5) açıkça kötü amaçlı kodun eklenmesine yol açabilecek olayları da kapsıyor.
Kendi SBOM'larınızda görünen bileşenlere göre filtrelenmiş, zaten takip ettiğiniz zafiyet istihbarat akışları.

Adım 3 — Yalnızca makul adayların çalması için koşulları kullanın

Kanalın inandırıcılığını koruyan adım budur. Echobell koşulları, şablonlarınızın kullandığı değişkenleri ve HTTP başlıklarını değerlendirir; kanal ancak ifade doğru olduğunda tetiklenir:

craCandidate == true && confirmed == true

Gönderen sistem gövdesini şekillendiremiyorsa bir başlık üzerinden kısıtlayın:

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

Eşiği "bu kesinlikle bildirilebilir" değil, "yetkin bir kişi buna bir saat içinde bakmalı" seviyesine koyun. Madde 14'ün devreye girip girmediğine karar vermek, olguları bilen bir insanın vereceği bir karardır; kanalın işi o insanı olgulara hızla ulaştırmaktır. Burada aşırı filtreleme pahalı bir hatadır, çünkü hiç başlatmadığınız bir bildirim, gereksiz gelen bir aramadan daha kötüdür.

Adım 4 — Yalnızca e-posta gönderen sistemleri yakalayın

Şirketinizin dışından gelen ilk temasın çoğu e-posta olarak ulaşır — araştırmacı, müşteri, ulusal CSIRT, bileşen tedarikçisi. Her Echobell kanalının kendi adresi olabilir; dolayısıyla security@ üzerindeki tek bir yönlendirme kuralı bu mesajları aramalara çevirir (e-posta tetikleyicileri).

E-posta tetikleyicileri from, to, subject, text ve html alanlarını değişken olarak sunar; böylece hiçbir şeyi ayrıştırmadan filtreleyebilirsiniz:

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

Düzenli bildirim gönderenlerden ve kilit tedarikçilerden üzerinde anlaşılmış bir konu işareti kullanmalarını isteyin, sonra bunu eşleştirin. Yapılandırılmamış bir gelen kutusunu yönlendirilebilir bir sinyale çeviren küçük bir sözleşme ayrıntısıdır.

Adım 5 — Kayıtlı her temsilciyi kanala ekleyin

Kanalı, bildirimi gerçekten gönderebilecek herkesle paylaşın: birincil yetkili temsilci, yedek temsilci ve Madde 14 kararını verebilecek güvenlik sorumlusu. Her abone kendi bildirim türünü seçer; böylece nöbetteki kişi Arama'da kalırken grubun geri kalanı Zaman Duyarlı'yı seçebilir.

Alıştırmanın amacı budur. SRP, kayıtlı ve doğrulanmış bir insan gerektirir. Şirketinizde kayıtlı tek bir kişi varsa 24 saatlik son tarihinizin, şarjı bitebilen bir telefona bağlı tek bir arıza noktası var demektir.

Adım 6 — 11 Eylül'den sonra değil, önce prova edin

Bu ay yapmaya değer iki prova:

Uyarı yolu. Rahatsız Etmeyin gerçekten açıkken, gerçekten birinin başucunda duracak telefonda yukarıdaki curl komutunu çalıştırın. Uygulamada Başarısız Aramayı Yeniden Dene seçeneğini açın ki bir kez başarısız olan arama yeniden denensin. Test edilmemiş bir eskalasyon yolu bir varsayımdır.
Bildirim yolu. Ağustos 2026'ya kadar güncellenen ENISA adım adım kayıt ve gönderim kılavuzlarını kullanarak bir raporu kâğıt üzerinde baştan sona yürütün (ENISA SRP). EU Login hesaplarını şimdi oluşturun, koordinatörünüzün hangi CSIRT olduğunu teyit edin ve yedek temsilci davetini erken gönderin — süresi yedi gün sonra doluyor.

İkinci provanın bilinmeye değer bir pürüzü var: ENISA'nın temmuz rehberi itibarıyla platformun genel URL'si hâlâ "lansmanda sağlanacak" olarak listeleniyordu, dolayısıyla canlı uçtan uca test henüz mümkün değildi (cyberresilienceact.eu). ENISA, platformun 11 Eylül 2026'ya kadar çalışır olacağını taahhüt etti. Kontrol edebildiğiniz her şeyi prova edin ve platformun hazır olmamasını kendi hazırlığınızı erteleme gerekçesi saymayın.

Echobell'in yapmadıkları

Konu düzenleyici olduğu için burada net olmak her zamankinden önemli:

Sizi uyumlu hâle getirmez. Echobell bir bildirim kanalıdır. Ürünlerinizin kapsamını belirlemek, bir zafiyet yönetimi süreci yürütmek, Madde 14'ün devrede olup olmadığına karar vermek, SRP'ye kaydolmak ve zamanında bildirim yapmak tümüyle sizin işinizdir. Hiçbir uyarı aracı bugüne dek bir raporlama yükümlülüğünü karşılamadı.
Hiçbir şey göndermez. Gönderim yapılacak bir API yok ve olsaydı bile onu çağıracak olan Echobell olmazdı. O bir telefonu çaldırır; gerisini kayıtlı bir insan yapar.
Hukuki bir zaman damgası değildir. {{time}} değişkeni, tetikleyicinin Echobell'e ulaştığı anı UTC olarak kaydeder. "Haberdar olmanın" ne zaman başladığı, kuruluşunuza ilişkin olgusal bir sorudur ve bunu bir push bildirimi değil, olay kaydınız belgeler.
Eskalasyon politikası ya da onaylama yoktur. "On dakika içinde kimse açmazsa sıradakini ara" diye bir şey, nöbet sırası ya da kimin neyi onayladığına dair denetim izi yoktur. Bunlar için bir olay platformuna ihtiyacınız var — bkz. Opsgenie alternatifleri.
İletimi garanti edemez. Bir arama; push altyapısına, ağa ve şarjı olan bir telefona bağlıdır. Bunu, bir olgunun ulaşmasıyla bir kişinin bilmesi arasındaki boşluğu kısaltan katman olarak görün, bir denetimde gösterebileceğiniz bir kontrol olarak değil.
Yerel saati izlemez. Yerleşik zaman değişkenleri yalnızca UTC'dir ve yaz saatini izlemez. Zaman aralığı sınırlayan koşullar yılda iki kez elle ayarlanmalıdır.

SSS

Echobell kullanmak bizi CRA uyumlu yapar mı?

Hayır. CRA üreticilere yükümlülükler getirir ve hiçbir bildirim uygulaması bunları yerine getiremez. Echobell'in ele aldığı şey belirli bir arıza biçimidir: 24 saatlik erken uyarı, bildirimi gönderebilecek kişi ertesi iş gününe kadar durumdan haberdar olmadığı için kaçırılır. Bu gerçek ve yaygın bir arıza biçimidir, ancak çok daha büyük bir uyum programının yalnızca bir parçasıdır.

24 saatlik sayaç gerçekte ne zaman başlar?

Üretici, aktif olarak istismar edilen zafiyetten veya ciddi olaydan haberdar olduğunda. Tüzük kesin bir an tanımlamaz; haberdar olmak olgulara ve bunların ne kadar hızlı ortaya konabildiğine bağlıdır (DLA Piper). Pratikte bu, hızlı ve belgelenmiş bir triyajı gerektirir: bir sinyalin gelmesiyle birinin onu değerlendirmesi arasındaki süre uzadıkça sonradan açıklamak zorlaşır.

Küçük bir şirketiz. Muaf mıyız?

Bildirimden değil. Madde 64, mikro ve küçük işletmeleri özellikle Madde 14(2)(a) ya da 14(4)(a)'daki 24 saatlik son tarihi kaçırmaya ilişkin idari para cezalarından muaf tutar. Bildirim yükümlülüğü sürer, 72 saatlik bildirim ve nihai rapor etkilenmez ve mikro işletme ile küçük işletme tanımlarını varsaymak size düşmez. Bunu bir geçiş belgesi değil, dar bir hafifletme olarak görün.

Güvenlik gelen kutumuz mesai saatlerinde izleniyor. Bu yetmez mi?

Yalnızca normal bir hafta sonunda sürenin üçte ikisine kadarını kaybetmeye razıysanız. Cuma 18.00'de gelen bir bildirim, size cumartesi 18.00'lik bir son tarih bırakır. Mesai saati izleme diğer her şey için gayet iyi bir varsayılandır; 24 saatlik sayaç ise tam da kapsamadığı durumdur.

Uyum, hukuk ve mühendislik aynı uyarıyı alabilir mi?

Evet ve almalılar. Tek bir kanalı paylaşın; aynı tetikleyicide her abone bildirim alır ve kendi aciliyetini seçer. İstismarı doğrulayan mühendis ile formu gönderecek kişinin ardışık değil, aynı dakikada başlaması gerekir.

Bu, Madde 14(8)'deki kullanıcıları bilgilendirme yükümlülüğüne yardımcı olur mu?

Dolaylı olarak. Madde 14(8), etkilenen kullanıcıların zafiyet ya da olay ve gerektiğinde düzeltici önlemler hakkında bilgilendirilmesini gerektirir. Bu bir müşteri iletişimidir ve kendi kanallarınızı gerektirir. Echobell, bu iletişimin sahiplerini bildirimin sahipleriyle aynı anda uyandırabilir; böylece iki iş kolu birlikte başlar.

Zaten NIS2 veya DORA kapsamında bildirim yapıyoruz. Bu aynı şey mi?

Hayır, biçimleri benzese de. NIS2 ve DORA, kuruluşlara sektör ve kritiklik temelinde yükümlülük yükler; CRA ise üreticilere AB pazarına sundukları ürünler temelinde yükümlülük yükler. Tek bir kuruluş, farklı sayaçlar ve farklı muhataplarla üçüne birden tabi olabilir. Bu rejimler de sizin için kapsamdaysa DORA ve NIS2 olay bildirimi uyarıları yazısına bakın — ve yükümlülükler ortak olmasa bile uyarı katmanının paylaşılabileceğini unutmayın.

Arama gerçekten Rahatsız Etmeyin modunu aşar mı?

Arama bildirimleri, arama tarzı uyarılar olarak iletilir; iOS'ta Odak Modu'nu aşmalarını sağlayan da budur. Bu sihir değil: yine de işletim sistemi ayarlarına, ağa ve şarjı olan bir telefona bağlıdır. Buna güvenmeden önce Odak Modu gerçekten açıkken, gerçek cihazda test edin — ve Başarısız Aramayı Yeniden Dene seçeneğini etkinleştirin.

Bu yalnızca iOS'ta mı var?

Hayır. Echobell hem iOS'ta hem de Google Play üzerinden Android'de mevcut (Android sürümü). Arama tarzı uyarı davranışı platformlar arasında farklılık gösterir, bu yüzden yanıt verecek kişinin gerçekten taşıyacağı cihazda test edin.

Webhook yüküne ne koymalıyız?

Yataktan kalkıp kalkmamaya karar vermek için gereken asgari bilgi: ürün, sinyalin türü, tek satırlık bağlam ve ayrıntıyı tutan kayda giden bir externalLink. Echobell bildirim içeriğini ve geçmişini cihazda tutar, sunucuda yalnızca hesapları, kanalları ve abonelikleri saklar (gizlilik modeli); yine de güvenlik açısından hassas materyalde doğru alışkanlık, içeriğin kendisini değil bir işaretçiyi göndermektir.