Cyber Resilience Act: 24 hores per avisar, i el rellotge no arrenca amb el CVE

El Cyber Resilience Act fa dos anys que és al calendari de tothom amb una data escrita: 11 de desembre de 2027. El que gairebé ningú tenia apuntat és que avui comença a aplicar-se un article solt, el 14, i que aquest article és l'únic que el mateix reglament estira cap enrere perquè abasti tot el que ja has venut. A partir d'aquest matí, un fabricant té 24 hores per donar el primer avís d'una vulnerabilitat que li estiguin explotant. I el termini no comença quan es publica el CVE ni quan surt la notícia: comença quan tu te n'assabentes. Que és un assumpte d'advocats només en part. La resta és qui llegeix què, i a quina hora. I arrenca un divendres.

Què arrenca avui, i què no

L'article 71 del Reglament (UE) 2024/2847 diu tres coses en dues línies: el reglament s'aplica des de l'11 de desembre de 2027, l'article 14 des de l'11 de setembre de 2026 i el capítol IV (organismes notificats) des de l'11 de juny de 2026. Res més. Avui no t'obliga el marcatge CE, ni els requisits essencials de l'annex I, ni la declaració de conformitat, ni el període de suport. Avui t'obliga una cosa: explicar el que t'està passant, a qui toca i dins de termini.

L'únic article que mira enrere

Aquí hi ha el detall que ens sembla el més important del dia i que gairebé no hem vist comentat. L'article 69.2 conté la bona notícia que tothom repeteix: allò que vas posar al mercat abans de l'11 de desembre de 2027 no queda subjecte al reglament, llevat que a partir d'aquella data el modifiquis substancialment. És el paràgraf que ha tranquil·litzat molta gent amb catàleg antic. El paràgraf següent, el 69.3, arrenca amb la fórmula «com a excepció al que disposa l'apartat 2 del present article» i diu que les obligacions de l'article 14 s'apliquen a tots els productes amb elements digitals dins de l'àmbit que s'hagin posat al mercat abans de l'11 de desembre de 2027.

Traduït: aquella versió que vas vendre el 2019 i que continua instal·lada en catorze clients no ha de complir ni un sol requisit tècnic del CRA. Però si algú l'està explotant i te n'assabentes a partir d'avui, tens 24 hores. Convé afegir-hi el límit, perquè també l'han hagut d'aclarir: si ja sabies abans d'avui que te l'estaven explotant, no cal notificar cap enrere. El que dispara el rellotge és assabentar-se'n, i prou. El legislador va posar primer el sensor i després la norma de producte. Sense el sensor, ningú no sap què passa aquí fora.

El rellotge: 24, 72 i 14

• 24 hores — avís primerenc. Sense demora indeguda i en tot cas dins de les 24 hores des que el fabricant en té coneixement. Contingut mínim: indicar, quan escaigui, en quins estats membres està disponible el teu producte. Aquest camp, que sembla burocràtic, és el que enxampa molta gent que no té la llista.
• 72 hores — notificació. Informació general del producte, naturalesa de l'exploit i de la vulnerabilitat, mesures correctores o mitigadores preses i les que pot aplicar l'usuari, més una indicació de com de sensible consideres la informació notificada.
• 14 dies — informe final. I aquí hi ha un matís que s'explica malament gairebé a tot arreu: els 14 dies no compten des de l'avís, compten des que hi ha una mesura correctora o mitigadora disponible. Si no n'hi ha, aquell termini no ha començat. Els altres dos sí.
• Incident greu: mateix 24 i 72, però l'informe final va a un mes des de la notificació de les 72 hores. I el CSIRT et pot demanar, si ho veu necessari, un informe intermedi pel camí.

Dues expressions decideixen si et toca

La primera és a l'article 3. El reglament defineix per separat «vulnerabilitat explotable» —la que té el potencial de ser usada per un adversari en condicions operatives pràctiques— i «vulnerabilitat explotada activament», que és aquella respecte de la qual hi ha proves fiables que un actor maliciós l'ha explotada en un sistema sense permís del propietari del sistema. Només la segona dispara el rellotge. I fixa't en què descansa la diferència: en «proves fiables». No en una sospita, no en un titular; en evidència. Si el teu producte no genera registres que permetin afirmar-ho o descartar-ho, el que tens no és tranquil·litat. És que no ho veus.

La segona expressió és a l'apartat 5, el que defineix quan un incident és «greu»: quan afecta negativament o és capaç d'afectar negativament la capacitat del producte de protegir la disponibilitat, autenticitat, integritat o confidencialitat de dades o funcions sensibles o importants; o quan ha portat o és capaç de portar a la introducció o execució de codi maliciós. És a dir: el reglament no mesura el dany consumat, mesura la capacitat. L'incident que gairebé surt malament també compta. Aquesta és la frase que sorprendrà més d'un la primera vegada que hagi de decidir a les onze de la nit si allò «no va ser res».

L'apartat 8, que gairebé ningú ha llegit

Tota la cobertura d'aquests dies va dels tres terminis cap a l'administració. L'article 14 té un apartat més, el 8, i és el que més ens interessa als qui vivim de fer que les coses funcionin: després de tenir-ne coneixement, el fabricant informarà els usuaris afectats —i quan escaigui, tots— de la vulnerabilitat o l'incident i, si cal, de les mesures que poden aplicar; quan correspongui, en un format estructurat i llegible per màquina. I després ve la frase: «quan el fabricant no informi els usuaris a temps, els CSIRT notificats podran facilitar aquesta informació als usuaris» si ho consideren proporcionat i necessari.

La nostra lectura, que no és la del reglament: aquella frase pesa més que la multa. Una sanció triga anys i la veu la teva assessoria. Que sigui el CSIRT qui avisi els teus clients d'un problema teu que tu no els havies explicat se sap la mateixa tarda, i es nota en la renovació següent. Si has de triar per on començar a muntar això, comença per aquí: per com avises tu, no per com omples el formulari.

Hem obert el formulari

La notificació no s'envia per correu: va per la plataforma única de notificació que estableix l'article 16 i que opera ENISA. Hi hem entrat avui a les 17:05 (hora peninsular): portal.cra-srp.enisa.europa.eu respon. Arriba puntual, cosa que a l'estiu semblava dubtosa. El que hi ha a l'altra banda, segons les preguntes freqüents que publica la mateixa ENISA, convé saber-ho abans i no amb el rellotge corrent:

• S'hi entra amb compte EU Login amb doble factor, i els comptes són personals: qui notifica fa servir el seu. Hi ha un representant assignat principal i secundaris, amb permisos diferents.
• L'associació entre el representant i el fabricant la valida el CSIRT designat, i ENISA avisa que el procediment i el temps de tramitació varien entre CSIRT i són responsabilitat de cadascun. La verificació va en paral·lel i no impedeix notificar mentre està pendent.
• No hi ha API a la versió inicial: es notifica a mà, per la interfície. I el notificació voluntària de l'article 15 tampoc no està disponible encara; arribarà en una fase posterior.
• Si tries malament el CSIRT coordinador, la notificació pot quedar invalidada i s'ha de tornar a presentar davant del correcte. Amb un termini de 24 hores, això no és un detall administratiu.
• El comptador de les 72 hores està malament en aquesta versió, i ho diu ENISA sense embuts: mostra el venciment 48 hores després que presentis l'avís primerenc, de manera que una notificació pot aparèixer com a fora de termini abans que hagin passat les 72 hores de debò. Ho arreglaran més endavant calculant-ho des de la data en què te'n vas assabentar. Mentrestant, el termini bo és el teu, no el del semàfor de la pantalla.
• Si la plataforma no està disponible, ENISA diu que esperis que torni; pots contactar directament amb el teu CSIRT si la urgència ho demana, però la notificació s'ha de presentar igualment per la plataforma quan torni.

I una recomanació d'ENISA amb la qual discrepem a mitges. Per no saturar de feina de validació els CSIRT, aconsella registrar-se i iniciar la validació només quan calgui notificar. S'entén per què ho diu, i afegeix que amb el compte EU Login actiu l'alta triga uns minuts. Però el dia que calgui notificar tindràs 24 hores, una sala plena de gent nerviosa i, amb força probabilitat, la persona que té el compte, fora. El compte EU Login amb doble factor, almenys de dues persones, sí que el faríem avui. És gratis i no dona feina a ningú.

A qui notifica una empresa espanyola?

Al CSIRT designat com a coordinador de l'estat membre on el fabricant tingui l'establiment principal a la Unió. I atenció a com ho defineix l'apartat 7, perquè no és el domicili fiscal: és l'estat membre on es prenen predominantment les decisions relatives a la ciberseguretat dels seus productes. Si no es pot determinar, el de l'establiment amb més empleats a la Unió. Si no hi ha establiment a la Unió, hi ha una cascada de quatre criteris: representant autoritzat, importador, distribuïdor i, en últim terme, on són la majoria dels usuaris. Per a un grup amb desenvolupament repartit entre dos països, aquesta és una pregunta real que convé tenir contestada per escrit abans, no a les tres de la matinada.

Per a Espanya, la llista de CSIRT coordinadors que publica ENISA remet a INCIBE-CERT, amb dues adreces diferents: la de resposta a incidents i la de coordinació de vulnerabilitats. És coherent amb el repartiment que ja coneixem —INCIBE-CERT per a entitats privades, CCN-CERT per al sector públic— i arriba, per cert, amb la transposició de NIS2 encara en tràmit parlamentari. El CRA és un reglament i no espera ningú: s'aplica directament. Ja vam escriure sobre aquesta asimetria quan el que arribava era el qüestionari de proveïdor de NIS2, i torna a passar el mateix.

I si no soc fabricant?

El reglament anomena fabricant qui desenvolupa o fa desenvolupar un producte amb elements digitals i el comercialitza sota el seu nom o marca, i hi afegeix un afegitó que a molts els canvia la resposta: «ja sigui a canvi de pagament, de monetització o de manera gratuïta». El plugin que regales també compta. I «producte amb elements digitals» inclou, per definició, les seves solucions de tractament remot de dades: la part al núvol sense la qual el producte no podria fer una de les seves funcions. Aquí és on moltes empreses de programari descobreixen que el seu servei no és tan «SaaS pur» com creien, i també on d'altres confirmen que en queden fora. Aquesta ratlla la traça un advocat amb el teu contracte al davant, no nosaltres.

Si no ets fabricant i només compres programari, avui no t'obliga res. Però et canvien dues coses. La primera: rebràs més avisos i abans, alguns de productes que ja havies donat per oblidats, i algú els ha de llegir i decidir. La segona: els teus proveïdors tenen des d'avui una obligació nova i concreta, i això es pot posar en un contracte amb una línia. Nosaltres l'escriuríem així: «en cas de vulnerabilitat explotada activament o incident greu amb impacte en la seguretat del producte, el proveïdor informarà everyWAN en un termini màxim de X hores des que en tingui coneixement, en els termes de l'article 14.8 del Reglament (UE) 2024/2847». És la mateixa pregunta que ja feia el qüestionari de NIS2, però ara amb una norma al darrere que la sosté.

La multa que circula i la seva lletra petita

El número que ha sortit aquests dies a la premsa és correcte i convé posar-lo en context. L'article 64.2 posa l'incompliment de l'article 14 al tram més alt, el mateix que els requisits essencials de l'annex I: fins a 15 milions d'euros o el 2,5% de la facturació mundial anual, la quantitat que sigui més gran. Dit d'una altra manera: no avisar a temps està tarifat igual que fabricar insegur. Ara la lletra petita, que també és al mateix article: les regles concretes de sanció les posen els estats membres, i l'apartat 10 eximeix microempreses i petites empreses de les multes per incomplir el termini de les 24 hores —només aquell; el de 72 i l'informe final no apareixen a l'excepció—. Curiosament, aquella exempció està redactada com a excepció als apartats 3 a 9, i les multes de l'article 14 són al 2. No som advocats i no interpretarem això: si el teu pla depèn d'aquella exempció, que t'ho miri algú que sí que ho sigui.

El que muntaríem, per ordre

1. Escriure què significa «tenir coneixement» a la teva empresa, i qui ho declara. És la peça que ningú no dona feta i de la qual penja tota la resta. Nosaltres ho aterrem en una cosa prosaica: un tiquet amb hora. El moment en què s'obre és el moment en què va arrencar el rellotge, i aquella marca de temps és la teva prova. Sense això, d'aquí a un any ningú no sabrà dir si l'avís va arribar en 20 hores o en 40.
2. Una sola porta d'entrada, i que estigui vigilada. Una bústia de seguretat publicada, una política de divulgació al teu web i una guàrdia real al darrere. La meitat de les vegades l'avís no arriba per la teva telemetria: arriba per un correu d'algú de fora. Si aquell correu aterra en una safata compartida que es llegeix els dilluns, el teu termini de 24 hores és ficció.
3. La llista de què vens i on. L'avís de les 24 hores demana els estats membres en els quals el producte està disponible. Versions vives, clients per país, quin component de tercers porta cadascuna. Si això no existeix, la primera hora de la crisi se'n va a reconstruir-ho, i aquella hora sortia del termini.
4. Dos comptes EU Login amb doble factor, fets avui. Costen zero i treuen del mig el tràmit que pitjor senta amb un incident a sobre. I amb ells, decidit i per escrit, quin és el teu CSIRT coordinador segons el criteri de l'article 14.7 —on es prenen de debò les decisions de ciberseguretat del teu producte—, no el del teu domicili social.
5. Telemetria que permeti dir «proves fiables» sense creuar els dits. Registres que sobrevisquin l'incident, en un lloc on l'atacant no els pugui esborrar, i prou senyal per distingir explotada d'explotable. Sense això, la notificació s'acaba escrivint amb conjectures.
6. Assajar-ho un dimarts qualsevol. Una hora, un supòsit inventat i el cronòmetre en marxa: qui declara el coneixement, qui redacta, qui entra a la plataforma, qui escriu als clients. El que no s'assaja no existeix, i ja ho hem escrit amb altres paraules parlant del pla de continuïtat que ningú ha assajat. Un procediment de notificació sense simulacre és exactament el mateix: un document.

Fixa't que dels sis punts, quatre no són de ciberseguretat: són d'organització. Passa el mateix amb gairebé tota la normativa europea d'aquests dos anys. Quan vam escriure sobre el que de debò aplicava de l'AI Act el 2 d'agost vam acabar al mateix lloc: el difícil arriba després, i és tenir escrit qui decideix què i en quant de temps.

El que no afirmem

No som advocats ni donem assessorament jurídic: tot el de dalt és lectura directa del text del reglament, que és públic i qualsevol pot contrastar, més la documentació operativa d'ENISA. No hem presentat cap notificació per la plataforma —no en tenim cap per presentar, afortunadament—, així que l'única cosa que en podem afirmar és que avui respon i el que diuen les seves preguntes freqüents. No sabem quantes empreses espanyoles queden dins de l'àmbit i no ho estimem. Tampoc no diem que la plataforma hagi de fallar: diem que el reglament no condiciona els terminis al fet que funcioni, i que això ho ha resolt ENISA per escrit dient que esperis i notifiquis igualment després. I un advertiment sobre nosaltres mateixos: everyWAN ven serveis de compliment i continuïtat, així que tenim un interès evident que això et preocupi. Per això hem citat article per article: perquè comprovis el text i no ens creguis a nosaltres.

Nota de fonts

Totes les dades d'aquest post s'han contrastat l'11 de setembre de 2026 amb el text del Reglament (UE) 2024/2847 (Cyber Resilience Act), llegit article per article: article 3 (definicions 1, 2, 13, 41 i 42), article 14 complet (els tres terminis de vulnerabilitat explotada i d'incident greu, el contingut mínim de cada notificació, l'informe intermedi de l'apartat 6, el criteri d'establiment principal i la cascada de l'apartat 7, i l'obligació d'informar els usuaris de l'apartat 8), article 16 (plataforma única, difusió i les seves excepcions), article 64 (trams de sanció i l'exempció de l'apartat 10 per a microempreses i petites empreses), article 69 (apartats 2 i 3, règim transitori) i article 71 (dates d'aplicació: 11 de desembre de 2027 amb caràcter general, article 14 des de l'11 de setembre de 2026 i capítol IV des de l'11 de juny de 2026). La part operativa prové de la documentació publicada per ENISA: la pàgina de la plataforma única de notificació i les seves preguntes freqüents (registre per EU Login amb doble factor, representants assignats principal i secundari, validació pel CSIRT designat amb temps que varien entre CSIRT, verificació en paral·lel que no impedeix notificar, absència d'API a la versió inicial, notificació voluntària de l'article 15 no disponible al llançament, invalidació de la notificació si es tria el CSIRT equivocat, què fer si la plataforma no està disponible i el consell de registrar-se només en necessitar notificar) i la seva llista de CSIRT designats com a coordinadors, que per a Espanya remet a INCIBE-CERT. La data d'entrada en aplicació i l'operativitat de la plataforma figuren a més a la pàgina d'obligacions de notificació del CRA de la Comissió Europea. El Reglament Delegat (UE) 2026/881, d'11 de desembre de 2025, és el que desenvolupa els motius per retardar la difusió de les notificacions previstos a l'article 16.2. La comprovació que portal.cra-srp.enisa.europa.eu respon és nostra, feta avui a les 17:05 hora peninsular. És lectura NOSTRA i no de les fonts: que l'article 14 sigui l'únic que el reglament estira cap enrere i el que això implica per al catàleg antic; que l'apartat 8 pesi més que la multa; que la definició de «proves fiables» converteixi el compliment en un problema de telemetria; la discrepància amb el consell d'ENISA sobre quan registrar-se; la clàusula de contracte proposada; i els sis punts de la llista. La fotografia de portada és «Echo Wall Clock», de bfishadow, publicada sota llicència Creative Commons CC BY 2.0.