GDC 2026 attendees, credit: GDC
On Sep 2, 2026, I took part in the Global Digital Collaboration Conference (GDC 2026) in Geneva, contributing to the panel “Operationalizing the Cyber Resilience Act: What manufacturers, Open Source stewards and security teams need now.” together with contributors from ETSI and Red Hat.
In his earlier post about GDC, Simone Onofri described the collaboration between standards organizations, implementers, and other communities that W3C brings to the conference. At the panel, I presented my contribution to ETSI EN 304 617, the draft European harmonized standard that provides cybersecurity requirements and assessment criteria for browsers under the Cyber Resilience Act (CRA).
The ETSI rapporteur responsible for EN 304 617 contacted W3C for feedback, and Simone Onofri, Luca Lumini, and I responded as participants in the W3C Security Interest Group (SING), signing our joint comments individually. ETSI then decided to restructure the draft, and I contributed to that work, as we described at the W3C breakout session in March 2026.
Bringing threat modeling into standards early
The thesis I presented argued that threat modeling should be integrated into technical standardization from the earliest stages. In the industry, it helps bring security and privacy considerations into technology development while mitigations can still be applied. The same reasoning applies to web and ICT standards, where threat modeling allows us to examine potential problems prior to ecosystem-wide adoption.
I introduced existing W3C efforts to bring threat and harm modeling into technical standardization, including the Threat Modeling Guide, the Threat Model for the Web, and the Threat Model for Decentralized Credentials. These are W3C Group Note Drafts, developed to help examine systems, identify threats and harms, and consider responses.
From a review comment to the revised browser draft
In support of my thesis, I presented a personal story. I started participating in the development of the ETSI browser standard for the CRA by commenting on its mature draft. In February 2026, I worked with Simone Onofri and Luca Lumini on joint structural feedback. We proposed several changes, including clearer product boundaries, requirements expressed through security outcomes, and references to the specifications that already define web security mechanisms.
We called for the explicit integration of threat modeling into Clause 4 and the risk-related annexes as a precursor to risk assessment. The idea was to describe the browser product through its components, data flows, and trust boundaries, and relate the threats and applicable requirements to that model.
Other organizations and stakeholders, including major browser vendors, had also commented on the mature draft. The public feedback on process architecture, for example, questioned requirements that could constrain the evolution of browser designs. The ETSI group responsible for that work item accepted some of the feedback and eventually decided to reboot the standard andI was invited, along with other people, to participate in that work.
I authored Clause 4 and Annex B, both of which are informative sections of the standard. I specifically referenced the W3C Threat Modeling Guide as a reference threat modeling methodology, including for responses to identified threats. I also referenced the W3C Threat Model for the Web for assets and threats. Since the July draft, Clause 4 describes the browser product, its context, and its architecture. Annex B proposes threat modeling as a precursor to risk analysis and risk acceptance.
When work already exists, it is much easier to reference it than to reinvent it or copy it. For browser cybersecurity requirements, it made sense to refer directly to the Threat Model for the Web published by the W3C Security Interest Group.
What I took from this experience
At GDC, I described the revised draft as being in much better shape. The draft advanced with threat modeling integrated into its structure. As of Sep 10, 2026, ETSI lists version 1.0.0 as being in the Public Enquiry stage.
I take that progression as an encouraging sign that threat modeling can fit within an established standardization process. It does not prove that threat modeling alone produced the result: the revision reflects many changes and the work of other contributors. My argument at the panel was to start this work earlier, before a mature draft needs substantial restructuring.