text: Regulation (EU) 2024/2847

text: of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations

text: (EU) No 168/2013

text: and

text: (EU) 2019/1020

text: and

text: Directive (EU) 2020/1828

text: (Cyber Resilience Act).

text: Figure 1: Survey infographic

text: Figure 2: Geographical spread and organisation size

text: Figure 3: Type of organisation

text: Figure 4: Envisioned CRA impact based on organisation size

text: Figure 5: Awareness of CRA obligations related to SBOMs

text: Figure 6: SBOM familiarity based on envisioned CRA impact

text: Figure 7: CRA influence on SBOM tooling and automation investments

text: Figure 8: Estimated time required to meet the target SBOM maturity level required by the CRA

text: Figure 9: Envisioned value of using SBOMs

text: Figure 10: Cybersecurity resources allocated to address concerns about supply chain security

text: Figure 11: Elements envisioned to improve supply chain security

text: Figure 12: Level of SBOM adoption based on organisation size

text: Figure 13: Engagement with SBOMs based on organisation size

text: Figure 14: Perception of SBOMs based on organisation size

text: Figure 15: Main barriers to adopting SBOMs

text: Figure 16: External support elements envisioned to accelerate SBOM adoption

text: ( ) Technical guideline BSI TR-03183: Cyber resilience requirements for manufacturers and products – Part 2: Software bill of materials (SBOM), available at https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183- 2_v2_1_0.pdf?__blob=publicationFile&v=5.

text: Figure 17: Types of SBOM format currently in use

text: Figure 18: SBOM generation tooling based on organisation size

text: Figure 19: SBOM production in Software Development Lifecycle (SDLC)

text: Figure 20: SBOM consumption during Software Development Lifecycle (SDLC)

text: Figure 21: SBOM automation level across different stages

text: Figure 22: COTS and SBOM based on organisation size

text: Figure 23: Level of SBOM depth needed and received

text: Figure 24: Primary use of SBOMs generated or received

text: Figure 25: Gap in generating and consuming SBOMs

text: Figure 26: SBOM tooling and automation investment

text: Figure 27:Envisioned approach to SBOM handling

text: Figure 28: Current challenges in leveraging SBOMs

text: Figure 29: SBOM adoption barriers

text: Figure 30: Elements improving the ability to produce or consume SBOMs

text: Figure 31: Importance of receiving vulnerability status from suppliers

text: Figure 32: Preferred methods for receiving vulnerability claims from suppliers

text: Figure 33: SBOM interoperability importance

text: Figure 34: Preferred SBOM delivery or interoperability methods

text: Figure 35: SBOM requirements in contracts

text: Figure 36: Suppliers providing adequate SBOMs

text: Figure 37: Main gaps in supplier’s SBOMs

text: Figure 38: Areas that would benefit from guidance or templates

identifier: SBOM Adoption State of Play - 2026

publisher: Europeiska unionens cybersäkerhetsbyrå

sprak: en

title: SBOM Adoption State of Play - 2026

serie: rapporter

text: TLP - CLEAR

type: rubrik

text: SBOM Adoption State of Play – 2026

text: Survey Results and Analysis JUNE 2026

text: SBOM Adoption State of Play – 2026

type: stycke

text: About ENISA

text: The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common level of cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the European Union Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and processes with cybersecurity certification schemes, cooperates with Member States and EU bodies, and helps Europe prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building and awareness raising, the Agency works together with its key stakeholders to strengthen trust in the connected economy, to boost resilience of the Union’s infrastructure, and, ultimately, to keep Europe’s society and citizens digitally secure. More information about ENISA and its work can be found here: www.enisa.europa.eu.

text: CONTACT

text: For contacting the authors, please use product_security@enisa.europa.eu For media enquiries about this paper, please use press@enisa.europa.eu.

text: AUTHORS

text: European Union Agency for Cybersecurity (ENISA)

text: LEGAL NOTICE

text: This publication represents the views and interpretations of ENISA, unless stated otherwise. It does not endorse a regulatory obligation of ENISA or of ENISA bodies pursuant to the

text: Regulation (EU) No 2019/881

text: . ENISA has the right to alter, update or remove the publication or any of its contents. It is intended for information purposes only and it must be accessible free of charge. All references to it or its use as a whole or partially must contain ENISA as its source. Third-party sources are quoted as appropriate. ENISA is not responsible or liable for the content of the external sources including external websites referenced in this publication. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication. ENISA maintains its intellectual property rights in relation to this publication. Luxembourg: Publications Office of the European Union, 2026

text: COPYRIGHT NOTICE

text: © European Union Agency for Cybersecurity (ENISA), 2026 This publication is licenced under CC-BY 4.0 ‘Unless otherwise noted, the reuse of this document is authorised under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence (https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed, provided that appropriate credit is given and any changes are indicated.

text: Copyright for the image on the cover and on pages 1:63 © Adobe Stock For any use or reproduction of photos or other material that is not under the ENISA copyright, permission must be sought directly from the copyright holders. ISBN 978-92-9204-791-7, DOI 10.2824/0741767

text: SBOM Adoption State of Play – 2026

text: Table of Contents

text: About ENISA 1 Executive Summary 3 1. Introduction 6 1.1 The Background 6 1.2 The Concept of SBOM 6 1.3 The Survey 7 2. Analysis of the SBOM State of the Art Survey 8 2.1 Survey Cohort 8 2.2 CRA Applicability, Awareness, Exposure and Investments 9 2.3 Supply Chain Security 12 2.4 SBOM Specifics 14

text: 2.4.1 Adoption Readiness 14

text: 2.4.2 Formats, Tools and Lifecycle Integration 17

text: 2.4.3 Usage Patterns and Gaps 20

text: 2.4.4 Barriers, Needs and External Supports 23

text: 2.4.5 Vulnerability Management 25

text: 2.4.6 Interoperability Requirements 26

text: 2.4.7 Supplier Requirements (for SBOM consumers) 27

text: 2.4.1 Guidance 29

text: 3. Conclusions 30

text: SBOM Adoption State of Play – 2026

text: Executive Summary

text: The EU Cyber Resilience Act (CRA) becoming fully applicable in December 2027, transforms the supply chain security landscape by making security-by-design and security-by-default, a legal obligation for all digital products entering the EU market. Software supply chain transparency thus becomes a required cybersecurity capability, positioning the Software Bill of Materials (SBOM) as an enabler and key mechanism for operational efficiency, vulnerability management, third-party risk management, and regulatory compliance.

text: SBOM is defined as a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements. It provides visibility of the components, libraries, dependencies and licencing requirements in a software product.

text: The European Union Agency for Cybersecurity launched a survey at the end of 2025 to gain factual data on how organisations across industries and of varying sizes are approaching SBOM adoption in response to the CRA. This report analyses the results of the SBOM state of the art survey, by discussing:

text: → CRA awareness, perceived applicability and organisational impact; → supply chain security concerns and investment plans for the identified risks; → SBOM familiarity and adoption levels; → SBOM formats, tooling ecosystem, integration patterns, depth and vendor supply; → SBOM implementation barriers, needs and external support; → SBOM interoperability requirements; → the guidance required to support SBOM adoption at scale.

text: The analysis confirms that the CRA acts as an accelerator for SBOM adoption as organisations broadly invest in SBOM generation and automation to integrate SBOM in the Software Development Lifecycle (SDLC), while expediting their implementation timeline to meet expected maturity levels. Based on the respondents’ estimations, 79% of the organisations will reach the necessary SBOM maturity level by the time that the CRA will be fully applicable.

text: Organisations acknowledged the value of continuously generating and consuming SBOM in risk reduction and cost avoidance (37 %), in operational efficiency (29 %) and in meeting contractual requirements and gaining a competitive edge in bids (26 %).

text: 78 % of the respondents reported that their organisations have already initiated their SBOM adoption journey, with 44 % currently being in the pilot or limited adoption phase. 9 % have already reached a mature level of implementation, fully supported by automation, while 25 % have stated that SBOMs are broadly adopted in their products.

text: The selected SBOM formats appear to align with the CRA requirement regarding using a format that is commonly used and machine-readable: 44 % of the respondents reported using CycloneDX and 29 % Software Package Data Exchange (SPDX). However, 11 % of the respondents indicated that they do not use a standard format and the remaining 17 % still use a proprietary format.

text: SBOM Adoption State of Play – 2026

text: The survey indicates that SBOM will be used for the identification and patching of vulnerabilities by 29 % of the organisations, for ensuring open-source licences (OSS) are correctly used/declared by 22 %, for meeting regulatory requirements by 19 %, for evaluating third-party software risks by 14 % and for maintaining an up-to-date inventory of all components by 13 % of the organisations.

text: The main barriers that prevent organisations from adopting SBOMs at scale, as identified by the respondents in different parts of the survey, are:

text: → the technical challenge of achieving a high degree of SBOM completeness (62 %); → the lack of internal skills or dedicated staff (28 %); → SBOM data quality (37 %); and → vulnerability matching (35 % quite a lot and 23 % extremely challenging).

text: The means that are going to facilitate this process have also been assessed by the respondents in different parts of the survey. It is clearly stated that external support is needed. The main needs can be summarised:

text: → a reference implementation providing the pipelines in a public repository; → a guide navigating the process of tool selection based on evaluations and benchmarking; → conformance tests with check point and validators; → industry consensus on best practices to integrate producing/consuming SBOMs: o into software development practices, deemed the most critical (23 %), o into risk and compliance processes (19 %), o how to produce/consume SBOMs and how these methods will evolve/improve over time (19 %); → development of a profile defining what constitutes a ‘good enough’ SBOM; → call for the standardisation of SBOM formats and their required fields; → development of a risk assessment framework that leverages SBOM data.

text: Overall, the survey findings indicate that SBOM adoption across organisations is progressing and is strongly influenced by the regulatory requirements introduced by the CRA. However, they also demonstrate that SBOM adoption fluctuates and further progress will depend on the development of shared implementation practices, improvements in supplier transparency, continued investment in workforce capabilities, and definition of the role of SBOMs within operational risk management frameworks.

text: SBOM Adoption State of Play – 2026

text: SBOM Adoption State of Play – 2026

text: 1. Introduction

text: 1.1 The Background

text: The EU Cyber Resilience Act (CRA) ( ), recognising the exponentially increasing cybersecurity challenges faced by the European Union, aims to enhance cybersecurity culture and strengthen cyber resilience across the EU market. These goals are fulfilled via a legal framework which lays out the essential requirements for the development of secure products with digital elements, ensuring security and transparency in the digital supply chain. It is a methodological and structured approach to target the low levels of built-in cybersecurity in many products, address the insufficient provision of security updates and help end users assess cybersecurity in the products that they consume. Along with other horizontal rules which address different aspects of cybersecurity, the CRA introduces for the first time the legal requirement for manufactures to create, maintain and, where necessary, share with market surveillance authorities Software Bill of Materials (SBOM) for all products with digital elements. This change transforms SBOMs from a best practice and optional implementation for supply chain security into a mandatory security measure upholding security, transparency and conformity with the regulation. SBOMs now play a multifaceted role in building market trust by facilitating informed, risk-based decision-making, providing traceability of products and components, supporting compliance and securing the supply chain.

text: 1.2 The Concept of SBOM

text: Under the CRA, the SBOM is defined as a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements. The SBOM obligations for manufacturers, outlined in the CRA, can be summarised as follows. • Manufacturers must generate SBOM for every product with digital elements they place on the EU market. • The SBOM must be in a commonly used and machine-readable format. • The SBOM must cover at least the top-level dependencies of the product. • The SBOM must be kept up to date throughout the product’s life cycle. • The SBOM must be included in the product’s technical documentation and provided to market surveillance authorities upon request. There is no obligation to make it public. • The SBOM must be included in the vulnerability handling process put in place by the manufacturer and support the identification and recording of vulnerabilities and components contained in products with digital elements.

text: SBOM Adoption State of Play – 2026

text: 1.3 The Survey

text: Given the significant role of SBOM in software supply chain transparency and security, along with its now mandatory nature as defined by the CRA, the European Union Agency for Cybersecurity (ENISA), with this survey, sought to examine SBOM readiness and the current state of SBOM adoption across various organisations and industries. The results provided meaningful insights on:

text: • the level of SBOM adoption and maturity; • the most common formats, tooling and usage scenarios; • perceived value, challenges, and the gap between SBOM generation and consumption.

text: The survey was divided into seven sections to gain targeted understanding on each subject area, from demographics to CRA awareness, SBOM predominant trends, adoption and maturity. Most questions were presented in multiple-choice format to facilitate pattern identification and the analysis of the results, while a few open-ended questions were included to gather specific insights. All responses were confidential and used only in aggregate.

text: The survey received 334 responses from organisations across the EU and, in some cases, beyond; almost 65 % of the respondents are EU-based organisations and more than 80 % are companies that are directly impacted by the CRA.

text: This report presents the analysis of the SBOM state of the art survey results conducted at the end of 2025 and has the following structure:

text: • Executive Summary • Section 1. Introduction • Section 2. Analysis of the SBOM State of the Art Survey • Section 3. Conclusions

text: SBOM Adoption State of Play – 2026

text: 2. Analysis of the SBOM State of the Art Survey

text: 2.1 Survey Cohort

text: The survey received mainly responses from private-sector companies (87.72 %). This was expected due to the CRA’s focus on manufacturers and importers of products with digital elements. Public authorities, trade associations and non-governmental organisations account collectively for approximately 8 % of the responses received.

text: Organisations with over 250 employees are heavily represented in the survey with more Large enterprises: 65 % of respondents than 65 % of the responses. Medium-sized enterprises represent 18 % while

text: Large enterprises have

text: microenterprises and small enterprises

text: the means and capacity

text: collectively represent 16 % of the

text: to be proactive and

text: respondents. This distribution potentially

text: prioritise innovation,

text: reflects the capacity and tendency of big

text: automation and

text: organisations to be proactive and explore

text: regulatory compliance.

text: compliance elements of EU policy and law ahead of time. This approach can also be explained by their involvement in both the legislative consultation process and the CRA Expert Group established by the European Commission.

text: Regarding geographical representation, 65 % of the respondents operate mainly within the EU, while 17 % are global operators, 13 % are North American and only 4 % are from Asia and the Middle East.

text: SBOM Adoption State of Play – 2026

text: Regarding sector representation, the IT and manufacturing sector represents 54 % of the responses, while more specific sectors (automotive, healthcare, financial, energy and telecommunications) represent lower percentages that do not exceed 35 % collectively.

text: 2.2 CRA Applicability, Awareness, Exposure and Investments

text: To establish a baseline understanding of how the CRA influences organisations across the EU ecosystem, we asked the respondents if and how the regulation is impacting their organisations. This question serves as an indicator of awareness and perceived applicability which can determine future activities to support the organisations based on their needs. By grouping the responses based on organisation size, we can identify the scope and target audience of the CRA while also obtaining an initial indication of anticipated maturity levels.

text: An interesting finding is that 80 % of small enterprises were directly impacted by the CRA either because they place products on the EU market or because they supply components to manufacturers. However, the focus mainly shifts towards the readiness journey of microenterprises, as 23 % of the respondents were either unsure if the CRA impacts their organisation or are currently exploring.

text: SBOM Adoption State of Play – 2026

text: In assessing organisations’ awareness of the CRA obligations related to SBOM, 87 % of the large enterprises provided a positive answer, while 13 % remain unaware. Nearly all medium-sized enterprises confirmed their awareness, whereas for 26 % of small enterprises still unclear.

text: Even though the results indicate a high level of awareness, it is important to acknowledge that there is still room for improvement for organisations of all sizes.

text: To better understand the relationship between organisational awareness and regulatory exposure, the survey examined how the respondents’ familiarity with SBOMs correlates with their perception of the CRA’s applicability to their organisation. This comparison provides insight into whether organisations that fall within the CRA’s anticipated scope are also developing the foundational awareness needed to operationalise these practices. The following results illustrate how SBOM familiarity varies depending on perceived CRA applicability, highlighting potential readiness gaps across the ecosystem.

text: While there is a broad familiarity with the concept of SBOM, varying from somewhat familiar to very familiar, most organisations which are unsure or currently assessing the impact of the CRA have never heard about SBOM before.

text: Noticeably, 33 % of those who answered that they have never heard about SBOM before also responded that their organisation is directly impacted by the CRA because it places products with digital elements on the EU market. This finding aligns with the high percentage (80 %) of organisations that report only recently hearing about SBOM yet also fall into the category of directly impacted organisations because they sell products with digital elements to end users.

text: Another finding is that among organisations which are still unsure or actively assessing if they are impacted by the CRA, a vast majority (67 %) reported never having heard about SBOM before, while 13 % had only recently become aware of it.

text: SBOM Adoption State of Play – 2026

text: In another effort to fully understand the impact of the CRA on organisations that fall under its scope, it is important to assess the financial impact and investment trends related to the implementation of its requirements. Using the SBOM requirement as a focal point, we asked the respondents to indicate if their organisation’s decision to invest in SBOM tooling and automation was influenced by the CRA.

text: Almost half of the respondents (43 %) indicated that the CRA has ‘significantly accelerated’ their investment in SBOM tooling and automation, while an additional 29 % indicated a ‘moderate influence’.

text: While, as depicted in Figure 7, almost 20 % indicated that the CRA itself did not play a role in the investment, it is worth highlighting the impact that the regulation has had on software development security.

text: This increase in investment seems to also have an impact on the expected timeline to meet the target SBOM maturity level required by the CRA, as reported by the respondents. As illustrated in Figure 8, 33 % of the respondents estimate they will reach the envisioned maturity level within 12 months (end of 2026), while 24 % anticipate requiring an additional six months. Meanwhile, 30 % indicated that they will require two years or more to reach this level, and 12 % were unable to provide an estimate.

text: SBOM Adoption State of Play – 2026

text: Investment decisions cannot only be supported by regulatory requirements if the end goal is to increase maturity and strengthen cyber resilience across the EU market. Implementors need to identify the value of these requirements. SBOMs could provide significant value in various use cases, security-related processes and business activities, but where do organisations obtain the greatest measurable value using SBOM?

text: Almost 37 % of the respondents acknowledged quite a lot of added value in risk reduction and cost avoidance, 29 % believed that SBOM adds quite a lot of value in operational efficiency, 26 % believed that SBOM will slightly add value to meeting contractual requirements and gaining a competitive edge in bids, while almost 26 % believed that SBOM will add quite a lot of value in making compliance and audit processes easier.

text: 2.3 Supply Chain Security

text: Exploring the key concerns about supply chain security and its impact on the financial decision-making of the organisations, the survey included questions on how concerned the organisations are about supply chain security and how they allocate resources (budget, staff or tooling) to manage the security of the software that they use.

text: SBOM Adoption State of Play – 2026

text: While there is broad acknowledgement that supply chain security matters, there is a gap in how this risk is addressed in terms of allocated budget. Noticeably, respondents with minimal to no concern dominate the limited investment space.

text: More than 90 % of respondents indicated they are concerned about the security of their supply chain; almost 60 % of them were very or extremely concerned. However, only 34 % of the respondents allocated significant or extensive resources to manage the security of the software they use.

text: To establish a better understanding of how organisations address supply chain security, we asked respondents to prioritise the most important activities for their organisations. The following heat map shows that the 1st priority with the most votes is secure development practices, with vulnerability reporting coming second and SBOM third. The prioritisation of the activities based on their importance can be easily interpreted based on the current practices of the industry and the regulatory requirements that have accelerated the standardisation of such activities.

text: It is important to highlight that 53 % of the respondents placed SBOM in their top three most important activities. SBOM is directly connected with both of the other two activities as it enables visibility of the software components, libraries and dependencies as well as monitoring license compliance, thus promoting secure software development practices while also providing targeted input for vulnerability reporting. This constitutes a major enabler for the broad adoption of SBOM generation and consumption.

text: SBOM Adoption State of Play – 2026

text: 2.4 SBOM Specifics

text: 2.4.1 Adoption Readiness

text: This section discusses organisational readiness in relation to the level of SBOM adoption, engagement and perception. The aim of this subject area is to understand the SBOM adoption journey of different types of organisations and how this is influenced by their size. The preliminary findings show how SBOMs are processed, highlighting the main barriers and the expected external support required to proceed with their implementation.

text: In Figure 12, based on the overall rating, we can identify that 78 % of the respondents reported that their organisations have already initiated their SBOM adoption journey, with 44 % currently being in the pilot or limited adoption phase. Only 9 % have reached a mature level of implementation, supported fully by automation, while 25 % stated that SBOMs are broadly adopted in their products.

text: An interesting finding has emerged at this point: microenterprises and small enterprises – representing 23 % and 25 %, respectively – have already reached a mature level of adoption. This contrasts sharply with medium-sized and large enterprises, which follow at much lower rates of 4 % and 6 %, respectively.

text: Assessing the overall outcome, medium-sized enterprises appear to lead the way, as the value for ‘Not yet started’ is 0 %.

text: SBOM Adoption State of Play – 2026

text: To understand better how the SBOM journey translates into operational activities, the respondents were asked to indicate how their organisations engage with SBOMs. Across all organisation sizes, the most popular answer was producing SBOMs for their own software. For small, medium-sized and large organisations, the second most popular manner of engagement was consuming SBOMs from their vendors or partners, whereas for microenterprises it was providing SBOM tools, solutions and/or integration services.

text: Regarding the respondents’ perception of SBOMs, the replies vary slightly depending on the size of the organisation. Overall, 28 % of respondents perceived SBOMs as a mandatory burden, which reveals a rather compliance-oriented approach, especially in large organisations where the percentage goes up to 36 %.

text: Regardless of the size of the organisation, SBOMs are prominently considered. Overall, by 42 % of respondents as a ‘defensive necessity’ (i.e., a vulnerability management approach), by 20 % as a ‘neutral inventory instrument’ and by 10 % as a ‘competitive asset’.

text: SBOM Adoption State of Play – 2026

text: This dual perception highlights an important transition phase within the ecosystem; while organisations recognise the technical value of SBOMs, many still associate their implementation with compliance pressure.

text: To have a more holistic perception of the status of SBOM adoption, it is crucial to understand the impediments that the organisations face throughout this process. The respondents were asked to assess the impacts of a variety of factors. The most commonly faced obstacle affecting them extremely is the lack of supplier/third-party SBOM availability and/or quality. Following closely is vulnerability matching (CPE/PURL alignment, false positives), with almost two thirds of the organisations being affected extremely or quite a lot, and data quality (incomplete components, identifiers, licences).

text: To overcome these barriers and accelerate SBOM adoption, the respondents have indicated the type of external support they wish to receive.

text: SBOM Adoption State of Play – 2026

text: 26 % of the organisations suggested that a reference implementation providing the pipelines in a public repository would be beneficial. 22 % would find it helpful to have a guide navigating the process of tool selection based on evaluations and benchmarking, while 18 % would prefer a suite providing conformance tests with check points and validators. All three activities indicated a need for technical guidance and support.

text: Figure 16 presents the respondents’ preferences regarding all the activities defined as external support.

text: 2.4.2 Formats, Tools and Lifecycle Integration

text: CycloneDX is indicated as the predominant SBOM format, with 44 %, while Software Package Data Exchange follows with 29 %. Interestingly, 11 % of the respondents indicated that they do not use a standard format and the remaining 17 % still use a proprietary format.

text: This result comes even though the CRA stipulates the use of ‘a commonly used and machinereadable format’ under Annex I, Part II (‘Vulnerability handling requirements’) and the Technical Guideline BSI TR-03183-2 ( ) indicates that ‘newly generated or updated SBOM must be in JSON- or XML-format and a valid SBOM according to CycloneDX, version 1.6 or higher [or] System Package Data Exchange (SPDX), version 3.0.1 or higher’.

text: It is worth highlighting that 28 % of the respondents represent a possible interoperability barrier at the EU market.

text: SBOM Adoption State of Play – 2026

text: Despite 33 % of overall SBOM generation relying on open-source tools, large and medium organisations rely a lot on commercial and proprietary tools as well. Interestingly though, reliance on manual processes across all company sizes sits at around 11 % overall, however in microenterprises it goes up to 16 %, introducing an additional hurdle since the CRA aims to provide security throughout the lifetime of products. 10 % of the respondents do not generate SBOMs at all.

text: Knowing when organisations are producing SBOMs in the Software Development Lifecycle provides valuable insights on the accuracy, trustworthiness and usefulness of SBOM data for vulnerability management, incident response and regulatory assurance. 39 % of the organisations reported that they produce SBOMs during software builds, 16 % during software delivery to an artifact registry or repository and 14 % during software deployment.

text: As the majority of organisations opt for build-time SBOM generation, it is safe to assume that they use them as an operational benefit, which also supports software supply chain trust.

text: SBOM Adoption State of Play – 2026

text: Following the same notion, the timing of SBOM consumption indicates if they are used proactively to prevent risks or reactively to detect and manage them after integration or deployment. 16 % reported that they consume SBOMs during software builds, 15 % during software integration and 14 % during the decision-making process determining if an external software is going to be used. Noticeably, the majority of the respondents don’t know if or how the SBOMs are consumed in their organisation.

text: Currently, SBOM generation and consumption spans all levels of organisational readiness. Fully automated implementation across each phase of the SBOM life cycle is the end goal for achieving maturity and reliability.

text: During this period of transition, 74 % of respondents reported that they have partially or fully automated SBOM generation for each release/build, 59 % have partially or fully automated the SBOM minimum content (only top-level dependencies) in machine-readable format (SPDX/ CycloneDX), 51 % have partially or fully automated the vulnerability handling workflow tied to SBOM, 52 % have partially or fully automated SBOM updates for the product support period and 39 % have partially or fully automated the inclusion of SBOM in their technical documentation.

text: SBOM Adoption State of Play – 2026

text: Regarding commercial off-the-self software (COTS) products purchased by organisations, we asked the respondents to indicate how often they receive SBOMs from the manufacturers that they collaborate with.

text: Overall, the vast majority of the responses were ‘Rarely’ and ‘Never’. 39 % of all organisations responded ‘Never’, 39 % ‘Rarely’, whereas only 2 % answered ‘Always’, implying that they have standardised this practice as an official process.

text: 2.4.3 Usage Patterns and Gaps

text: SBOM depth is crucial to determine if an organisation is effectively identifying risks in transitive dependencies, build components and runtime environments. Figure 23 presents the level of SBOM depth that organisations need versus what they receive.

text: A big gap between the need and actual result has been identified: 36 % of respondents stated that their organisations need all primary components and direct dependencies with declared known unknowns but only 29 % actually receive them, 24 % of the organisations need SBOMs with full depth analysis but only 14 % receive them, while 27 % require SBOMs with depth analysis including declared known unknows and only 12 % receive them.

text: SBOM Adoption State of Play – 2026

text: Besides the gap between the organisational needs and how they are addressed, it is important to highlight the percentage of respondents who stated that they do not know what SBOM depth their organisation needs versus what they receive.

text: The information provided by the SBOMs based on their depth was primarily used for the identification and patching of vulnerabilities by 29 % of the organisations, for ensuring opensource licences (OSS) are correctly used/declared by 22 %, for meeting regulatory requirements by 19 %, for evaluating third-party software risks by 14 % and for maintaining an up-to-date inventory of all components by 13 %.

text: As depicted in the following figure, the respondents indicated that the primary stakeholders of SBOM consumption were the security and application security teams (34 %) and the development and engineering teams (34 %). The legal/compliance teams and procurement teams made limited use of SBOM information, with only 15 % and 5 % of the organisations, respectively, stating that these teams consume SBOM.

text: As shown in Figure 25, 44 % of respondents reported a ‘moderate gap’ between generating SBOMs and utilising them while 23 % reported a ‘significant gap’. Only 7 % have closed the gap entirely, which indicates that SBOMs are not actively used to their full extent for security but instead mainly for compliance purposes.

text: SBOM Adoption State of Play – 2026

text: In an effort to close this gap, organisations are strategically investing in SBOM tooling and automation. The survey results show that 34 % of the organisations have invested in tools dedicated to vulnerability handling via SBOM, 21 % in automating the inclusion of SBOM in the product’s technical documentation for market surveillance authorities, 19 % in tooling generating SBOM for all primary components with all transitive dependencies and their metadata (achieving full completeness) in a machine-readable format and another 19 % in automating the continuous update of SBOMs throughout the product’s support period.

text: Based on the identified gaps and investment strategies among the organisations, the envisioned approach to SBOM handling is depicted in Figure 27. 41 % of the organisations reported that they aim to fully automate SBOM generation for each release/build. Only 26 % of respondents believed that their organisations will fully automate SBOM updates across the product support period and almost 23 % believed that their organisations will partially automate this process. A concerning result is that almost 32 % believed that their organisations will automate the SBOM minimum content in machine-readable format while almost 22 % believed that their organisations will partially automate this process. This raises concerns about the quality, accuracy and usefulness of SBOMs. What comes as a surprise, though, is that most organisations are planning to partially automate vulnerability handling workflows tied to SBOM, raising concerns about the ability to efficiently identify hidden risks in the software components.

text: SBOM Adoption State of Play – 2026

text: To interpret the envisioned approach to SBOM handling, we need to understand the current challenges that organisations are facing. Figure 28 presents the challenges in leveraging SBOMs today.

text: When asked about the technical challenge of achieving a high degree of SBOM completeness, 62 % of the respondents answered with quite a lot or extremely difficult. At the same time, when asked about the lack of quality and complete vendor-supplied SBOMs, 30 % of respondents answered with quite a lot and 27 % with extremely. When asked about the lack of internal skills or dedicated staff, respondents answered with moderate (29 %) or quite a lot (28 %).

text: 2.4.4 Barriers, Needs and External Supports

text: Diving deeper into the main barriers that prevent organisations from adopting SBOMs at scale, the respondents were asked to rate the challenges presented in Figure 19.

text: As shown in the heat map, data quality (37 %), supplier/third-party SBOM availability/quality (31 % quite a lot and 30 % extremely), vulnerability matching (35 % quite a lot and 23 % extremely) and process ownership/governance (33 % moderate) were rated as the main barriers that could jeopardise the broad adoption of SBOM across organisations.

text: SBOM Adoption State of Play – 2026

text: Solely identifying the main barriers is not enough, so the respondents needed to provide their opinion on what would be useful to their organisations to improve their ability to produce and/or consume SBOMs.

text: Industry consensus on best practices to integrate producing/consuming SBOMs into software development practices was deemed the most critical (23 %), followed by industry consensus on best practices to integrate producing/consuming SBOMs into risk and compliance processes (19 %) and industry consensus on how to produce/consume SBOMs and how these methods will evolve /improve over time (19 %).

text: SBOM Adoption State of Play – 2026

text: 2.4.5 Vulnerability Management

text: Receiving vulnerability status or exploitability claims from suppliers was rated ‘critical’ by 39 % and ‘important’ by 37 % of respondents, as shown in Figure 31. Together, this accounts for 76 % of respondents, underscoring the significance of the coordinated vulnerability disclosure approach outlined in the CRA. As depicted in Figure 32, their preferred options for receiving such claims were automatically (44 %) or via a standardised application programming interface (API) (40 %).

text: SBOM Adoption State of Play – 2026

text: 2.4.6 Interoperability Requirements

text: SBOM interoperability was rated ‘critical’ by 30 % and ‘important’ by 39 % of the respondents. As shown in Figure34 their preferred options to ensure delivery and interoperability were through machine interfaces (32 %) and by supporting the conversion and compatibility between formats (30 %).

text: SBOM Adoption State of Play – 2026

text: 2.4.7 Supplier Requirements (for SBOM consumers)

text: Only 10 % of respondents reported that their organisation had established mandatory SBOM requirements within supplier contracts. Assessing the overall responses, company size does not appear to significantly influence the adoption of this practice, as the reported percentages remain broadly consistent across organisation sizes, with the exception of medium-sized enterprises.

text: It is essential though to highlight that 55 % of the respondents were in the process of including SBOM requirements in their supplier contracts in a systematic and consistent manner. 37 % indicated that they already include them in an ad hoc manner, while 27 % were planning to include them.

text: Incorporating SBOM requirements into contractual obligations can significantly expand the pool of suppliers that align with the expectations of organisations. 45 % of organisations reported that only 0 % to 25 % of their suppliers meet their requirements, while just 2 % indicated that 75 % to 100 % of their suppliers meet these expectations. This highlights a substantial gap in supplier readiness that contractual SBOM requirements could help improve.

text: SBOM Adoption State of Play – 2026

text: As depicted in Figure 37, supplier readiness gaps are primarily identified in three areas. Specifically, 27 % of respondents reported that supplier-provided SBOMs do not meet completeness requirements, 17 % indicated that SBOM component identifiers lack sufficient accuracy and 12 % highlighted issues related to the quality or adequacy of vulnerability references. These findings point out the quality challenges in supplier-generated SBOMs.

text: SBOM Adoption State of Play – 2026

text: 2.4.1 Guidance

text: Targeted external guidance is expected to support organisations across the EU market in overcoming barriers, responding to organisational needs and accelerating the SBOM adoption progress.

text: In particular, 31 % of respondents considered the development of a profile defining what constitutes a ‘good enough’ SBOM to be beneficial, 29 % called for the standardisation of SBOM formats and their required fields, and 20 % saw value in the development of a risk assessment framework that leverages SBOM data.

text: SBOM Adoption State of Play – 2026

text: 3. Conclusions

text: The SBOM SoA survey provides factual data on how organisations across industries and of varying sizes are approaching SBOM adoption in response to the CRA. Overall, the results demonstrate that the CRA is already acting as a meaningful enabler for SBOM implementation, while also revealing some maturity gaps, operational challenges, and areas where further ecosystem alignment is required to enable sustainable adoption at scale.

text: A central conclusion from the survey is that the CRA, while still in transitional period is already shaping organisational investment priorities and capability development. Respondents indicated that the regulation is acting as an accelerator for SBOM adoption. This demonstrates that the regulation is functioning as an early market signal influencing security engineering practices, supply-chain transparency, and compliance strategies.

text: Respondents reported that their organisations are progressing in their SBOM adoption journey, with expectations to reach a level of maturity aligned with CRA expectations within planned timeframes. Technical external support is needed to accelerate SBOM adoption at scale across all organisations, with the need for an SBOM Reference Implementation ranking #1.

text: The value of SBOMs is identified in risk reduction, cost avoidance and operational efficiency. SBOMs are primarily viewed as a defensive cybersecurity mechanism, particularly supporting vulnerability management, licence compliance and regulatory compliance activities. These use cases align closely with the expectations established under the CRA and broader secure-by-design frameworks.

text: There is a strong alignment across respondents regarding format-related requirements. Respondents broadly recognised that SBOMs must be provided in commonly used and machine-readable formats to support supply chain transparency at scale. This alignment is consistent with the expectations articulated in the CRA and reflects the fact that interoperability is not just a technical preference but a requirement for operationalising SBOM.

text: SBOM Adoption State of Play – 2026

text: Respondents indicated that SBOMs are increasingly generated and consumed during build-stage activities, suggesting a direct integration into software development pipelines rather than a post-release documentation activity. Such integration represents an important step towards achieving continuous transparency across the software life cycle, supporting timely vulnerability analysis and facilitating more effective risk management.

text: While many respondents reported producing SBOMs with full dependency depth, others indicated that their current practices remain limited to primary components and direct dependencies. Deeper dependency visibility is essential for effective vulnerability management and supply-chain risk management, enabled by comprehensive SBOM coverage with full transparency across transitive dependencies.

text: Despite progress, respondents identified several challenges affecting implementation quality and scalability. Among the most frequently cited were SBOM completeness, data quality limitations, and shortages of internal skills and specialised staff. These challenges reflect that SBOM adoption is not just a tooling issue, but also an organisational capability issue requiring process adaptation and workforce development.

text: Respondents expressed concern about the absence of widely accepted industry best practices for integrating SBOM production and consumption into both software development workflows and organisational risk management processes. The lack of consensus in this area is one of the most significant challenges identified. These findings indicate that organisations are not only seeking technical specifications or standards but also operational guidance.

text: Respondents highlighted various priority areas where further support would accelerate adoption. These include the development of a profile defining what constitutes a ‘good enough’ SBOM for practical use, the standardisation of SBOM formats and required data fields and the establishment of a risk assessment framework capable of leveraging SBOM information.

text: TP -01 -26 -008 -EN -N

text: ABOUT ENISA

text: ENISA

text: European Union Agency for Cybersecurity

text: Athens Office

text: Agamemnonos 14 Chalandri 15231, Attiki, Greece

text: Brussels Office

text: Rue de la Loi 107 1049 Brussels, Belgium

text: enisa.europa.eu


text: Notice must be taken that this publication represents the views and interpretations of the authors and editors, unless stated otherwise. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the

text: Regulation (EU) No 526/2013

text: . This publication does not necessarily represent state-of the-art and ENISA may update it from time to time. Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication. This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication.

text: © European Union Agency for Network and Information Security (ENISA), 2014 Reproduction is authorised provided the source is acknowledged. ISBN 978-92-9204-113-7, doi 10.2824/320219

text: 3.1 FIRST 1

text: 3.1.1 Membership Process 1 3.1.2 Activities 2

text: 3.2 TF-CSIRT/Trusted Introducer 2

text: 3.2.1 Membership Process 2 3.2.2 Activities 3

text: 3.3 NSP-Security 3

text: 3.4 EU FI-ISAC 3

text: 4.1 FIRST 4

text: 4.2 TF-CSIRT 4

text: 4.3 NSP-Security 4

text: 4.4 EU FI-ISAC 4

text: http://www.terena.org/activities/tf-csirt/ http://www.trusted-introducer.org/

text: Scalable and Accepted Methods for Trust Building in Operational Communities

text: European Union Agency for Network and Information Security www.enisa.europa.eu

text: About ENISA

text: The European Union Agency for Network and Information Security (ENISA) is a centre of network and information security expertise for the EU, its member states, the private sector and Europe’s citizens. ENISA works with these groups to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. More information about ENISA and its work can be found at www.enisa.europa.eu.

text: Authors

text: Lionel Ferette

text: Contact

text: For contacting the authors please use cert-relations@enisa.europa.eu For media enquires about this paper, please use press@enisa.europa.eu.

text: Acknowledgements

text: The author would like to thank the experts who provided the information that fed this report, and the thriving communities that are its subject. The author gratefully acknowledges the continuous support and valuable feedback from Jo De Muynck, Andrea Dufkova, and Marco Thorbruegge (ENISA).

text: Legal notice

text: Copyright Notice

text: Page ii

text: Executive summary

text: One of ENISA’s role is that of community builder. In order to properly fulfill this role, ENISA must have a better insight at what makes or breaks a community – trust. This report takes a first informal look at how communities build and maintain trust, by looking at four different operational communities. We highlight commonalities and differences, and give a first set of recommendations to enhance trust in a community.

text: Page iii

text: Table of Contents

text: Executive summary iii 1 Introduction 1 2 Defining Trust 1 3 A look at operational communities 1 4 Discussion 4 5 Conclusions 5 6 References 5

text: Page iv

text: 1 Introduction

text: As shown in previous ENISA reports [1] [2] [3], trust is a cornerstone for cooperation between CERTs [1] and it is instrumental for valuable information sharing among operational communities in general. As such, participation in trust building activities is one of ENISA’s recurrent recommendations [2]. This document takes an informal look at existing operational communities that single out trust building as being one of their goals. Its purpose is to get preliminary insight before going into further details in the scope of a future Work Programme. The communities we look at are not only CERT-related, as the problem of trust building goes beyond the world of CERTs and can be applied to any community made either of individuals or teams that need to collaborate occasionally.

text: 2 Defining Trust

text: Trust can be defined in terms of a set of expectations [3]. Previous work by ENISA [4] shows that CERTs that meet the following expectations are more likely to be trusted by other CERTs:  Technical expertise  Active membership in CERT initiatives  Ability to respond quickly and act on security threats  Stability of the team  Maturity level of the team

text: In other words, a trusted CERT is mature team that acts on shared information and shares back. It should be noted that even with this kind of definition, trust is established gradually: first, people trust people, then people trust teams, and finally teams trust teams.

text: 3 A look at operational communities 3.1 FIRST

text: The Forum of Incident Response and Security Teams (FIRST ) was founded in 1990 as a worldwide network of individual computer security incident response teams that cooperate voluntarily to improve their abilities to deal with and prevent computer security problems. FIRST is a membership organisation that is governed by an operational framework, and each member must designate a primary and alternate representative to FIRST. Participants in FIRST are part of a network of teams that voluntarily work together in order to deal with response to computer security problems and their prevention. FIRST’s approach to trust is twofold:

text: 1. Control the entrance of new members

text: 2. Provide activities that foster trust

text: 3.1.1 Membership Process

text: FIRST members are mostly teams, though individuals can apply. Teams willing to become members need to provide basic information about how to contact them and their policies. New candidates must also have two existing teams supporting their membership (“sponsors”). Usually, a representative of one of the sponsors performs a site visit to meet the new team and their management, and assess its

text: Page 1

text: level of maturity – funding, security policies and other operational factors. The visiting sponsor then reports to the membership committee that decides on new memberships. It should be noted that membership is for life. Once a team has been admitted, there is no re-evaluation (this makes the FIRST model different from the TF-CSIRT/TI model for example).

text: 3.1.2 Activities

text: FIRST provides activities and structure for information sharing:  Mailing lists for discussion: in principle, these lists can be used to discuss any subject with the whole community. However, given the large number of participants and the uncertainty of who will receive the mails, these lists are seldom used for sensitive information.  Workshops (Technical Colloquium, Special Interest Groups, Symposium, etc.): these activities gather members in small to medium groups that have similar interests or are geographically close, and are focused on technical issues. One or several team representatives present their projects, or ask for feedback, or train others. It is at this level that most trust is established, as groups are small and closed enough to foster the sharing of information.  Conference: the annual conference gathers representatives of teams from all over the world, but membership is not a requirement to register. The information shared in sessions is thus seldom of sensitive nature, but the numerous side activities leave room for personal contact.

text: 3.2 TF-CSIRT/Trusted Introducer

text: TF-CSIRT provides a forum where members of the CSIRT community can exchange experiences and knowledge in a trusted environment in order to improve cooperation and coordination. It maintains a system for registering and accrediting CSIRTs, as well as certifying service standards. TF-CSIRT’s approach to trust is similar to that of FIRST, but goes a bit further: 1. Control the entrance of new members 2. Provide activities that foster trust

text: 3. Provide an additional maturity level

text: 3.2.1 Membership Process

text: As with FIRST, members are mostly teams. Individuals are only admitted by invitation of the community. The cornerstone of TF-CSIRT membership is the “Trusted Introducer” . This service serves as a neutral and trusted third party that introduces new teams to the community. The first step for a team to join the community is to acquire “Listed” status with Trusted Introducer. This requires two sponsors (already accredited teams) that can testify that the candidate team is a CERT in good standing, and very basic contact information. Full membership additionally requires full contact information, as well as summaries of key policies like the Information Sharing policy. By and large, the information gathered is closely mapped to RFC2350 [5], augmented by statements regarding the team’s support for a number of good practices. Certification is the next level of maturity for member teams. By getting certified, a team demonstrates that it meets certain criteria as evaluated by a neutral third party.

text: Page 2

text: The biggest difference with FIRST is that all levels of participation must be regularly confirmed in order to maintain the privileges that are associated with them:  Listed teams need to confirm their contact information once a year,  Full Members need to update the whole of their information every four months, and  Certification is only valid for three years, after which the whole certification process must be renewed.

text: 3.2.2 Activities

text: The activities are similar to FIRST, so we will focus on the differences that can have an influence on trust:  Closed meetings. The closed meetings are reserved for full members, and the focus is on sharing information that is not public.  Use of the Traffic Light Protocol. Use of the TLP is institutionalised during meetings, and teams are encouraged to share Amber and Red level information during the closed meeting.  Encrypted mailing lists. There are mailing lists that encrypt any message for each recipient individually. This allows to share more sensitive information. They are not often used, though.  Out of Band Alerting System. Teams can use an alerting system that reaches all other teams through text messages in case of major emergencies.

text: 3.3 NSP-Security

text: NSP-Security is a low profile community of volunteer incident responders. It revolves around a mailing-list, and individuals willing to participate must satisfy a number of requirements: 1. Work for a corporation that is in position to actively handle incidents (ISP, vendor …), and use a corporate email address. 2. Action is mandatory, contribution is encouraged. All members are encouraged to share information on the mailing list, and acknowledge actions. Those prevented by laws or policies from doing so are required to take action whenever it is in their purview. 3. Reposting information outside the mailing list is forbidden. It should be noted that the last two requirements can be at odds with each other, as acting on information might require notifying others. Also, the mailing list is not encrypted. On top of the above requirements, side activities are organised during various security conferences to allow members to meet each other in person.

text: 3.4 EU FI-ISAC

text: The EU FI-ISAC is the Information Sharing and Analysis Centre for the European Financial Institutions. It gathers together individual representatives from Financial Institutions (banks, central banks …), CERTs, and Law Enforcement. Its purpose is information sharing about incidents, threats, trends, vulnerabilities, etc., in the financial sector. The approach of the EU FI-ISAC to trust is as follows: 1. Mandatory use of the TLP. Participants are encouraged to share Amber or Red information.

text: Page 3

text: 2. Participants sign an NDA before each meeting. 3. Mandatory contribution. Contribution is taken in the largest sense possible, but systematic silence is not tolerated.

text: 4. Continuity. As much as possible, people in the group should remain the same over time.

text: 4 Discussion

text: In this section we discuss how each community fares with regard to the criteria listed in Section Error! eference source not found..

text: 4.1 FIRST

text: FIRST is a CERT initiative, so its very existence is a trust building mechanism for its members. However, its size and the single level of maturity (membership) means that just being a fellow member will not automatically make a team trustworthy to another one. The size of FIRST also makes its mailing list almost devoid of sensitive information, because teams do not know who else is subscribed. This is where the other activities play an important role: participation in the conference, symposia, and other face-to-face meetings allow teams to meet each other. Those who actually present their experiences or tools during these activities will get extra credit, because they will show expertise and a sharing mind-set. However, speaking slots are limited, and experience shows that the same teams or even the same persons present their results, while the rest passively absorbs the information. With regards to the ability to act on information, FIRST as an organisation can do little: they have no control on what data a team will receive, and how they will actually act on it.

text: 4.2 TF-CSIRT

text: Since TF-CSIRT shares a similar organisational form to that of FIRST, it’s no surprise that the trust situation is similar in some aspects. The mailing list is seldom used for sensitive information sharing, and during meetings the same teams and people are presenting, and are thus more easily trusted. Likewise, TF-CSIRT has little control on the way a team treats information it receives. The difference lies in the tiered membership. It gives a lot more credit to certified teams. The distinction between closed and open meetings, with TLP Amber or Red information being shared only in the closed meeting, allows for a closer-knit community. Also, the number of accredited teams is still small enough that being a fellow member can be enough for a basic trust relationship.

text: 4.3 NSP-Security

text: Contrary to FIRST and TF-CSIRT, NSP-Security is made up of individuals. The need for vetting new members and the mandatory taking of action makes for a high level of trust between members. The downside of only having individual members is that there is no automatic way for the trust relationship to be transferred to the members’ organisation or company.

text: 4.4 EU FI-ISAC

text: As for NSP-Security, members are vetted, and participation is mandatory. The biggest difference is that a neutral trusted third party is vetting the participants. The EU FI-ISAC is also organised around regular physical meetings. This provides the framework for a high level of trust between participants – over time. The downside is scalability: speaking slots are limited during face to face meetings, and

text: Page 4

text: there is only so many persons one can talk to during an informal social event that usually accompanies the meetings.

text: 5 Conclusions

text: We considered four operational communities whose goals include fostering trust between their members. All of them are successful in a certain way, though some scale better than others. An important observation is that all consider human contact important – even the one based solely on a mailing list, NSP-Security. This leads to a first recommendation that organisations need to dedicate time and resources to the participation of face to face meetings. Sharing and personal contact is one of the most important factors in establishing trust. Formal presentations during meetings are one of the most obvious ways of providing opportunities for sharing. However, as the number of members in a community grows, the number of speaking slots limits scalability. This situation can be improved in several ways:  Encourage speaker rotation  Vary the format of meetings by providing space for active discussion  Propose side activities that allows personal contact

text: ENISA should keep investigating ways of improving trust building in operational communities in the future, with a more rigorous approach.

text: 6 References

text: [1] ENISA, “Baseline Capabilities of National/Governmental CERTs - Update Recommendations 2012,” 2012. [2] ENISA, “Baseline Capabilities of National / Governmental CERTs - Part 2: Policy Recommendations,” 2010. [3] F. Fukuyama, Trust: The Social Virtues and The Creation of Prosperity, Free Press, 1996. [4] ENISA, “Deployment of Baseline Capabilities of National/Governmental CERTs - Status Report 2012,” 2012. [5] N. Brownlee and E. Guttman, “Expectations for Computer Security Incident Response,” June 1998. [Online]. Available: https://www.ietf.org/rfc/rfc2350.txt.

text: Page 5

text: C at al o gu e N u m b er TP -05 -14 -117

text: -EN -N

text: ENISA

text: European Union Agency for Network and Information Security ISBN number: 978-92-9204-113-7 Science and Technology Park of Crete (ITE) doi: 10.2824/320219 Vassilika Vouton, 700 13, Heraklion, Greece

text: Athens Office

text: 1 Vass. Sofias & Meg. Alexandrou Marousi 151 24, Athens, Greece

text: PO Box 1309, 710 01 Heraklion, Greece Tel: +30 28 14 40 9710 info@enisa.europa.eu Page 6 www.enisa.europa.eu

type: vagledning

utgivare: enisa