Cyber Resilience Act (CRA) 2026: 24/72 Saat Güvenlik Açığı ve Ciddi Olay Bildirimi
Cyber Resilience Act 2026 bildirim zorunluluğu, AB’ye yazılım, IoT cihazı, ağ ekipmanı, bağlı tüketici ürünü veya başka dijital unsurlu ürün satan Türk şirketleri için 11 Eylül 2026 itibarıyla teorik gelecek uyumu olmaktan çıktı. CRA, ürün güvenliği ile siber güvenliği tek düzenleyici çerçevede birleştiriyor. Tüzük 10 Aralık 2024’te yürürlüğe girdi; genel uygulama tarihi 11 Aralık 2027 olmakla birlikte, m.14’teki güvenlik açığı ve ciddi olay bildirim yükümlülükleri daha erken, 11 Eylül 2026 tarihinde uygulanmaya başladı.
| CRA yükümlülüğü | Tarih / süre |
|---|---|
| m.14 güvenlik açığı ve ciddi olay bildirimi | 11 Eylül 2026 itibarıyla uygulanıyor |
| İlk erken uyarı | Farkına varılmasından itibaren 24 saat |
| Ayrıntılı bildirim | Kural olarak 72 saat |
| CRA genel ürün uygunluk hükümleri | Esas olarak 11 Aralık 2027 |
| Uygunluk değerlendirme kuruluşlarına ilişkin bazı hükümler | Tüzüğün kademeli takvimine göre daha erken uygulanır |
Cyber Resilience Act ne zaman uygulanıyor?
CRA, 20 Kasım 2024 tarihli Regulation (EU) 2024/2847 olarak kabul edilmiş ve 10 Aralık 2024’te yürürlüğe girmiştir. Tüzüğün genel uygulama tarihi 11 Aralık 2027dir. Ancak m.71 geçiş takvimi bazı hükümleri daha erken tarihte uygulamaya sokar.
11 Eylül 2026 bakımından en önemli erken uygulama hükmü Article 14tır. Bu madde, üreticinin aktif olarak istismar edilen güvenlik açıklarını ve ürünün güvenliğini etkileyen ciddi olayları bildirmesini düzenler. Dolayısıyla “CRA 2027’ye kadar uygulanmıyor” cümlesi 16 Eylül 2026 itibarıyla eksik ve yanlıştır.
Resmî Tüzük metnine EUR-Lex – Regulation (EU) 2024/2847 üzerinden, AB Komisyonunun uygulama rehberlerine European Commission – Cyber Resilience Act sayfasından ulaşılabilir.
CRA hangi ürünleri kapsıyor?
CRA’nın merkezindeki kavram “product with digital elements” yani dijital unsurlar içeren üründür. Bu kavram, yazılım veya donanım ürünü ile bunun uzaktan veri işleme çözümlerini, ürünün fonksiyonu için gerekli oldukları ölçüde kapsar. IoT cihazları, akıllı ev ekipmanları, ağ ürünleri, bağlı oyuncaklar, bazı yazılımlar ve diğer dijital bileşenli ürünler bu çerçevede değerlendirilebilir.
Tüzük her dijital sistemi aynı şekilde kapsamaz. CRA’da tıbbi cihazlar, motorlu taşıtlar, havacılık ve belirli özel sektör düzenlemelerine tabi bazı ürünler için kapsam istisnaları veya özel rejim bağlantıları vardır. Bu nedenle şirketin ilk adımı “ürün elektronik mi?” sorusu değil, CRA tanımı ve istisnaları bakımından ürün sınıflandırması olmalıdır.
Ürünün bir fiziksel cihaz değil yalnız yazılım olması da otomatik kapsam dışı sonucu yaratmaz. Ticari olarak piyasaya arz edilen yazılım, ürün niteliğine ve dağıtım modeline göre CRA kapsamına girebilir. Buna karşılık hizmet olarak sunulan bazı salt çevrimiçi hizmetler farklı AB siber güvenlik düzenlemeleriyle kesişebilir.
Türkiye’deki üretici CRA’dan neden etkilenir?
CRA, AB pazarında dijital unsurlar içeren ürünlerin piyasaya arzını düzenler. Türkiye’de yerleşik üretici AB’ye ürün satıyorsa, ürünün AB’de piyasaya arzı CRA koşullarına tabi olur. AB’deki ithalatçı, dağıtıcı veya yetkili temsilci rolleri somut tedarik zincirine göre belirlenir.
11 Eylül 2026’da başlayan m.14 bildirim yükümlülüğü esas olarak manufacturer üzerinde kuruludur. Türkiye’de ürünün tasarımını/üretimini yapan ve kendi adı/markasıyla AB pazarına sunan şirket, CRA üretici tanımı bakımından değerlendirilmelidir. Başka bir AB şirketinin markasıyla üretim yapılıyorsa sorumluluk zinciri sözleşmede ayrıca açıklaştırılmalıdır.
AB ithalatçısının varlığı, Türk üreticinin güvenlik açığı bilgisini saklama veya bildirim zincirini geciktirme hakkı vermez. Özellikle m.14’te süreler çok kısa olduğu için sözleşmede “önce müşteri onayı alınır, sonra bildirim yapılır” gibi düzenlemeler yasal sürenin kaçırılmasına neden olabilir.
AB’ye ambalajlı teknoloji ürünü gönderiliyorsa CRA yanında ambalajın da PPWR’ye uygunluğu gündeme gelebilir. Bu ayrı yükümlülük için AB Ambalaj Tüzüğü PPWR 2026 rehberimize bakılabilir.
“Aktif olarak istismar edilen güvenlik açığı” ne demektir?
CRA bakımından bildirim yükümlülüğü her teorik veya potansiyel zafiyet için aynı anda doğmaz. M.14’ün erken bildirim sistemi özellikle actively exploited vulnerability kavramına odaklanır. Bu, kötü niyetli bir aktörün güvenlik açığından fiilen yararlandığına ilişkin güvenilir kanıt bulunan durumu ifade eder.
Şirketin yalnız CVE kaydı yayımlandığı için otomatik olarak “aktif istismar” sonucu çıkarması gerekmez; ancak kendi telemetri kayıtları, müşteri olayları, güvenlik araştırmacısı bildirimi, CSIRT/ENISA uyarısı veya güvenilir tehdit istihbaratı aktif istismarı gösterebilir.
Hukuki risk, “kesin kanıt bekleyelim” denilerek 24 saatlik sürenin aşılmasıdır. CRA’nın kademeli bildirim sistemi zaten ilk 24 saatte tüm teknik ayrıntıların hazır olmasını beklemez. Erken uyarının amacı, yetkili makamların olayı hızla görmesini sağlamaktır.
24 saat içinde hangi bildirim yapılmalı?
Üretici, aktif olarak istismar edilen bir güvenlik açığından haberdar olduğu andan itibaren 24 saat içinde erken uyarı göndermelidir. Aynı yaklaşım ürünün güvenliğini etkileyen ciddi olaylarda da uygulanır.
İlk bildirimde olayın veya zafiyetin niteliği, mümkünse etkilenen üye devletler ve mevcut temel bilgiler verilir. 24 saatlik erken uyarı, soruşturmanın tamamlandığı nihai rapor değildir. Üreticinin “root cause analysis bitmedi” veya “yama henüz hazır değil” gerekçesiyle ilk bildirimi bekletmesi bu sistemle uyumlu değildir.
Şirket içinde “farkına varılma anı”nın kayıt altına alınması gerekir. SOC kaydı, güvenlik ekibi ticket’ı, e-posta, müşteri destek kaydı veya araştırmacı bildirimi gibi ilk güvenilir farkındalık anı bildirim süresinin hesaplanmasında önem kazanabilir.
72 saatlik ayrıntılı bildirimde ne bulunur?
Erken uyarıyı takiben üretici, kural olarak 72 saat içinde daha ayrıntılı bildirim yapar. Aktif olarak istismar edilen güvenlik açığı bakımından bu bildirim, ürün ve açığın genel tanımını, kötüye kullanımın niteliğini, varsa alınan düzeltici veya hafifletici önlemleri ve gerekli diğer teknik bilgileri içerir.
Bu süre de olayın tamamen kapatıldığı nihai rapor süresi değildir. CRA, üreticinin kısa sürede kamu otoritesiyle gerekli bilgiyi paylaşmasını ve daha sonra soruşturma ilerledikçe nihai bilgileri tamamlamasını öngören aşamalı sistem kurar.
72 saatlik rapor hazırlanırken hukuk, siber güvenlik, ürün mühendisliği ve iletişim ekiplerinin aynı olay kaydı üzerinden çalışması gerekir. Bir ekibin “incident”, diğerinin “vulnerability”, üçüncüsünün “customer complaint” olarak ayrı kayıt açması süre ve kapsam hatasına neden olabilir.
Aktif istismar edilen güvenlik açığında nihai rapor ne zaman verilir?
CRA m.14 sistemi, erken uyarı ve 72 saatlik bildirimin ardından düzeltici veya hafifletici tedbirler kullanıma sunulduktan sonra nihai rapor aşamasını da düzenler. Üretici, güvenlik açığının tanımı, temel nedeni, etkilenen ürünler, istismarın sonuçları ve düzeltici/azaltıcı önlemler hakkında tamamlanmış bilgiyi yetkili sisteme sunmalıdır.
CRA m.14 uyarınca aktif olarak istismar edilen güvenlik açığında nihai rapor, düzeltici veya hafifletici önlemin kullanıma sunulmasından sonra en geç 14 gün içinde sunulur. Ürünün güvenliğini etkileyen ciddi olayda nihai rapor ise 72 saatlik ayrıntılı bildirimden itibaren en geç bir ay içinde sunulur. Şirketin iç prosedürü yalnız 24 ve 72 saati değil, bu nihai rapor sürelerini de ayrı son tarih olarak takip etmelidir.
Yama yayınlandıktan sonra dosyayı “teknik olarak kapatmak”, CRA bildirim dosyasının da otomatik kapandığı anlamına gelmez. Nihai rapor ve kullanıcı iletişimi tamamlanmalıdır.
“Severe incident impacting the security of the product” ne demektir?
CRA yalnız güvenlik açığını değil, ürünün güvenliğini etkileyen ciddi olayları da m.14 bildirimine tabi tutar. Bir olay, ürünün güvenliğini etkileyen ve örneğin zararlı yazılımın uygulanması, veri bütünlüğü/gizliliği/erişilebilirliği üzerinde ciddi etki veya yetkisiz erişim gibi sonuçlarla bağlantılı olabilir.
Ciddi olay ile aktif istismar edilen güvenlik açığı bazen aynı olay zincirinde bulunabilir; ancak hukuken aynı kavram değildir. Bir zafiyet aktif olarak istismar edilebilir, olay henüz geniş etki yaratmamış olabilir. Tersine, ciddi ürün güvenliği olayı farklı bir teknik nedenden kaynaklanabilir.
Ciddi olayda da ilk erken uyarı 24 saat içinde, ayrıntılı olay bildirimi kural olarak 72 saat içinde yapılır. Nihai rapor ise olayın ele alınması, kök neden ve düzeltici önlemler tamamlandıkça CRA’nın öngördüğü zaman çizelgesine göre verilir.
Bildirim nereye yapılır?
CRA, bildirimler için ENISA tarafından işletilen single reporting platform yapısını kurar. Bildirim, ENISA ve üreticinin ana kuruluş yerinin bulunduğu veya ilgili kriterlere göre belirlenen üye devletin CSIRT koordinatörüyle bağlantılı sistem üzerinden yürütülür.
Türkiye’de yerleşik üreticinin AB’de yerleşik olmaması, raporlama mimarisinin önceden belirlenmesini daha da önemli hale getirir. AB yetkili temsilcisi, ithalatçı, ana pazar ve ürünün satıldığı üye ülkeler dikkate alınarak hangi CSIRT koordinasyon kanalının kullanılacağı hukuk ve güvenlik ekiplerince önceden belirlenmelidir.
Olay meydana geldikten sonra “hangi ülkeye bildireceğiz?” sorusunun araştırılması 24 saatlik erken uyarı süresini gereksiz yere tüketir. Şirketin CRA olay müdahale planında platform hesabı, sorumlu kişiler ve yedek erişimler hazır olmalıdır.
Üretici kullanıcıları da bilgilendirmek zorunda mı?
CRA, yalnız kamu otoritesine rapor göndermeye dayalı kapalı bir sistem kurmaz. Üretici, aktif olarak istismar edilen güvenlik açığının etkisini azaltmak için gerekli olduğunda etkilenen kullanıcıları bilgilendirmeli; uygulanabilecek düzeltici veya hafifletici önlemler konusunda açık bilgi vermelidir.
Patch, firmware update, credential reset, konfigürasyon değişikliği veya ürünün belirli işlevinin geçici olarak kapatılması gibi önlemler kullanıcıya somut biçimde anlatılmalıdır. “Güncellemeleri yapınız” gibi soyut ifade, kritik güvenlik adımını açıklamak için yeterli olmayabilir.
Kullanıcı bildiriminin zamanlaması güvenlik riskini de dikkate almalıdır. Zafiyet ayrıntısının erken ve kontrolsüz açıklanması saldırganlara yol gösterebilir; buna karşılık kullanıcıyı hiç bilgilendirmemek sömürü riskini artırabilir. CRA’nın yetkili otorite sistemiyle koordineli açıklama stratejisi izlenmelidir.
Açık kaynak veya üçüncü taraf bileşenden gelen zafiyet kimin sorumluluğunda?
Bir ürünün zafiyeti üçüncü taraf kütüphane, açık kaynak bileşen, firmware modülü veya tedarikçi yazılımından kaynaklanabilir. Bu durum ürün üreticisinin CRA m.14 bakımından sorumluluğunu otomatik olarak ortadan kaldırmaz. Üretici, kendi ürününün etkilendiğini öğrendiğinde bildirim şartlarını değerlendirmelidir.
Bu nedenle Software Bill of Materials (SBOM), bileşen envanteri ve tedarikçi güvenlik bildirim kanalları uygulamada kritik hale gelir. Şirket hangi ürün sürümünde hangi kütüphane sürümünün bulunduğunu bilmiyorsa yayımlanan CVE’nin kendi ürününü etkileyip etkilemediğini 24 saat içinde belirlemekte zorlanır.
Açık kaynak geliştiricisinin ticari faaliyetten bağımsız konumu ile ürünü ticari olarak AB pazarına sunan üreticinin CRA sorumluluğu ayrılmalıdır. Tedarik sözleşmesinde güvenlik açığı bildirimi, patch süresi ve teknik veri paylaşımı ayrıca düzenlenmelidir.
11 Aralık 2027’de hangi CRA yükümlülükleri genişleyecek?
CRA’nın genel uygulama tarihi 11 Aralık 2027 olduğunda, üreticilerin dijital unsurlu ürünleri esas siber güvenlik gereklerine uygun tasarlaması, güvenlik risk değerlendirmesi, uygunluk değerlendirmesi, teknik dokümantasyon, CE işaretlemesi ve güvenlik destek süreci gibi geniş ürün uygunluk sistemi tam olarak uygulanacaktır.
Bu nedenle 2026’daki m.14 raporlama yükümlülüğü “şimdilik yalnız olay raporla, ürün güvenliği tasarımına 2027’de başla” şeklinde yorumlanmamalıdır. 2027’de piyasaya sunulacak ürünlerin secure-by-design, vulnerability handling ve teknik dosya süreçleri bugünden hazırlanmalıdır.
Özellikle uzun ürün geliştirme çevrimi bulunan router, endüstriyel kontrol cihazı, akıllı ev ürünü ve gömülü yazılım üreticilerinin 2026’da tasarladığı ürün 2027 sonrasında piyasaya sunulacaksa CRA tasarım gerekleri proje başında dikkate alınmalıdır.
AB distribütör ve ithalatçı sözleşmesine hangi maddeler eklenmeli?
- CRA bakımından tarafların manufacturer/importer/distributor rolünü açıkça tanımlayın.
- Güvenlik açığı veya ciddi olay bilgisinin karşı tarafa iletilmesi için maksimum iç süre belirleyin; bu süre yasal 24 saati tehlikeye atmamalıdır.
- SBOM ve ürün sürüm bilgisinin hangi formatta tutulacağını belirleyin.
- CVE/CSIRT/araştırmacı bildirimlerinin hangi kişiye gönderileceğini düzenleyin.
- Patch, firmware ve düzeltici önlem geliştirme sorumluluğunu yazın.
- ENISA/CSIRT bildirimini kimin yapacağını ve diğer tarafın hangi bilgiyi sağlayacağını belirleyin.
- Kullanıcı bilgilendirmesi, geri çağırma veya güncelleme maliyetinin paylaşımını düzenleyin.
- Alt tedarikçi ve açık kaynak bileşenlerinde güvenlik bildirim yükümlülüğünü zincire aktarın.
- 2027 uygunluk dosyası ve CE süreci için teknik dokümantasyon teslimini şimdiden sözleşmeye ekleyin.
Uluslararası sözleşme risklerinin genel çerçevesi için ticari sözleşmeler hukuku sayfamız; AB’ye ürün gönderimindeki ambalaj sorumluluğu için PPWR 2026 rehberimiz tamamlayıcıdır.
Şirket içinde CRA 24/72 saat olay planı nasıl kurulmalı?
İlk adım, ürün envanterinin CRA kapsamı bakımından sınıflandırılmasıdır. İkinci adım, her ürün için ürün sahibi, security lead, hukuk sorumlusu ve AB bildirim sorumlusunun belirlenmesidir. Üçüncü adım, “farkına varılma” anını kayıt altına alan tek ticket/incident sistemi kurulmasıdır.
Plan en az şu akışı içermelidir: güvenilir zafiyet/olay sinyali → etkilenen ürün/sürüm tespiti → aktif istismar veya ciddi olay sınıflandırması → 24 saat erken uyarı → 72 saat ayrıntılı bildirim → düzeltici önlem ve kullanıcı iletişimi → nihai rapor → kök neden ve süreç iyileştirmesi.
İşletme yılda en az bir masa başı tatbikat yapmalıdır. Örnek senaryoda AB müşterisinden cuma akşamı aktif istismar bildirimi geldiğinde hafta sonu/mesai dışı süreçte kimin karar vereceği test edilmelidir. Yasal süre mesai günü kavramına bağlı değildir.
KVKK veya GDPR veri ihlali bildirimi CRA bildirimini yerine geçirir mi?
Hayır. Bir siber olay kişisel veri ihlali yaratıyorsa GDPR ve/veya KVKK kapsamındaki veri ihlali yükümlülükleri ayrıca gündeme gelebilir. CRA m.14 ise ürünün güvenlik açığı ve ciddi güvenlik olayı için ürün siber güvenliği odaklı ayrı bir bildirim sistemidir.
Aynı olayda birden fazla düzenleyici bildirim gerekebilir. Şirketin olay planı CRA, GDPR, NIS2 ve sözleşmesel müşteri bildirimlerini tek olay kaydında koordine etmeli; bir raporun diğer düzenleyici yükümlülüğü otomatik kapattığı varsayılmamalıdır.
Sık sorulan sorular
Cyber Resilience Act tamamen 2026’da mı yürürlüğe girdi?
Hayır. Tüzük 2024’te yürürlüğe girdi; genel uygulama 11 Aralık 2027’dir. Ancak m.14 güvenlik açığı ve ciddi olay bildirimleri 11 Eylül 2026’da uygulanmaya başladı.
Aktif istismar edilen güvenlik açığı kaç saatte bildirilir?
Üretici, haberdar olduktan sonra 24 saat içinde erken uyarı ve kural olarak 72 saat içinde daha ayrıntılı bildirim yapmalıdır.
Her CVE 24 saatte ENISA’ya bildirilir mi?
Hayır. M.14 erken bildirim yükümlülüğü özellikle aktif olarak istismar edildiği bilinen güvenlik açıklarına yöneliktir. Bununla birlikte bütün zafiyetler ürün güvenliği ve vulnerability handling sürecinde değerlendirilmelidir.
Türkiye’deki üretici de bildirim yapmak zorunda mı?
Ürün AB pazarına sunuluyorsa üreticinin CRA statüsü ve tedarik zinciri değerlendirilir. Türkiye’de yerleşik olmak, AB’ye piyasaya arz edilen ürün bakımından CRA sorumluluklarını otomatik olarak ortadan kaldırmaz.
Bildirim sadece AB ithalatçısına yapılırsa yeterli mi?
Hayır. Sözleşmesel ithalatçı bildirimi, CRA m.14’teki ENISA/CSIRT düzenleyici bildiriminin yerine geçmez.
Patch hazır olmadan 24 saatlik bildirim yapılabilir mi?
Evet. İlk 24 saatlik bildirim erken uyarıdır; Tüzük bütün teknik soruşturmanın veya yamanın tamamlanmasını beklemez.
CRA CE işareti bugün zorunlu mu?
CRA’nın genel ürün uygunluk ve CE rejimi esas olarak 11 Aralık 2027’de uygulanacaktır. Ürünün başka AB mevzuatı nedeniyle bugün zaten CE yükümlülüğü bulunabilir.
Açık kaynak kütüphanedeki zafiyet üreticiyi etkiler mi?
Kütüphane üreticinin AB pazarındaki ürününde kullanılıyorsa ve ürün etkileniyorsa üretici CRA yükümlülüklerini değerlendirmelidir. Üçüncü taraf bileşen sorumluluğu otomatik olarak ortadan kaldırmaz.
CRA bildirimi GDPR ihlal bildirimini yerine geçirir mi?
Hayır. Aynı olayda CRA, GDPR/NIS2 ve sözleşmesel bildirimler ayrı ayrı uygulanabilir.
Bakırcı & Keskin Hukuk Bürosu
Bu yazı genel hukuki bilgilendirme amacı taşır; ürünün CRA kapsamı, ekonomik işletmeci rolü, zafiyet/olay sınıflandırması ve bildirim kanalı somut ürün ve AB tedarik zinciri bazında ayrıca incelenmelidir.
Hukuki konu hakkında iletişim
İlk iletişimde konuyu, bulunduğunuz ülke veya ili ve varsa tebliğ ya da son işlem tarihini kısaca belirtebilirsiniz. T.C. kimlik numarası, sağlık verisi veya kişisel belge göndermeyiniz. Mesajlaşma tek başına hukuki görüş veya avukatlık ilişkisi oluşturmaz.
