Jochen Michels, Director Public Affairs Europe, Kaspersky
In today’s highly regulated digital environment, organizations that purchase security solutions must look beyond marketing claims and assess concrete, verifiable attributes. Four pillars – regulatory compliance, effective risk mitigation, operational transparency, and security‑by‑design – serve as a benchmark for judging whether a cybersecurity vendor can be trusted to protect critical assets and to operate within the legal frameworks of the European Union.
Compliance as the legal foundation
Compliance is the baseline that guarantees a product or service can be offered legally across the EU. The EU Cyber Resilience Act (CRA) defines a set of essential cybersecurity requirements for “products with digital elements” and obliges economic operators to provide a CE‑mark, an EU Declaration of Conformity, and complete technical documentation. Meeting these obligations demonstrates that a vendor’s offering has been evaluated against harmonized standards and can be placed on the internal market without breaching Union law. The NIS 2 Directive adds a second layer of mandatory obligations at the corporate level. Registration as an “Essential Entity”, as in the case of Kaspersky, requires a documented risk‑management framework, timely incident reporting, and dedicated supply‑chain security controls.
Geopolitical risk considerations
European organizations increasingly face threats that originate from state‑backed actors, export‑control restrictions, and supply‑chain disruptions. A trustworthy provider must therefore extend its risk‑mitigation scope to address these geopolitical dimensions:
- Threat‑intel integration – Correlate vulnerability data with intelligence on nation‑state campaigns, ensuring that patches for exploits linked to hostile actors are prioritized.
- Resilience‑by‑design – Deploy redundant data centers in multiple EU Member States, reducing the impact of cross‑border restrictions or geopolitical shutdowns on service availability.
- Incident‑reporting to authorities – Align with NIS 2 reporting timelines while also notifying the European External Action Service when an incident is linked to a foreign intelligence service, thereby satisfying both cyber‑security and foreign‑policy reporting obligations.
When a provider aligns its risk‑mitigation measures with geopolitical risks and both CRA and NIS 2 expectations, customers gain confidence that incidents will be reported to authorities promptly, that remediation will be swift, and that the overall security posture will improve despite a volatile international environment.
Transparency – access to code, rules, and documentation
Transparency converts compliance and risk data into a shared, auditable resource. The CRA mandates that market‑surveillance authorities receive “access to data and documentation” from economic operators. A provider that goes beyond the minimum requirement can demonstrate trustworthiness through several concrete mechanisms, e.g.:
- Source‑code review – allowing access to the source code of security‑critical components (or at least the parts that implement detection logic) in a read‑only repository – enables independent auditors, academic researchers, and national CSIRTs to verify that the code follows secure‑development best practices and contains no hidden backdoors.
- Transparency centers – Physical or virtual facilities where regulators and accredited third parties can inspect the development environment, view build pipelines, and observe the deployment process in real time. Such centers reinforce confidence that the vendor’s internal controls match its public statements.
- Access to threat‑detection rules – Providing the exact signatures, heuristics, and machine‑learning models used by the product, together with versioning information, allows customers to assess detection coverage and to integrate the rules into their own security information and event management (SIEM) platforms.
- Open software‑development lifecycle (SDLC) documentation – Publishing detailed descriptions of the SDLC, including threat modelling artefacts, code‑review policies, and automated testing procedures, demonstrates that security is embedded throughout development rather than added after release.
- Software Bill of Materials (SBOM) – Supplying a machine‑readable SBOM for every released version satisfies the CRA’s requirement for “technical documentation” (Annex VII) and enables downstream users to identify third‑party components, verify license compliance, and assess supply‑chain risk.
By making source code, detection logic, and SBOMs available for public authorities, regulators, customers, and partners – while protecting legitimate intellectual‑property concerns through read‑only access or controlled‑view environments – a vendor creates a verifiable evidence base. Regulators can, for example, confirm adherence to the CRA, auditors can perform independent assessments, and customers can demonstrate due‑diligence to their own oversight bodies.
Security‑by‑design – embedding protection from the start
Security‑by‑design shifts protection from an after‑the‑fact add‑on to an intrinsic characteristic of a product or service. The CRA requires that products be “secure by default,” meaning encryption, least‑privilege configurations, and hardened defaults must be enabled out‑of‑the‑box. NIS 2 reinforces this principle by obligating essential entities to adopt secure development practices, including threat modelling and supply‑chain risk assessments. A vendor that integrates these requirements into its development lifecycle delivers several tangible benefits: reduced attack surface, fewer post‑release patches, and a clearer path to certification. Moreover, publishing a “Security‑by‑Design Playbook” that outlines the technical controls, coding standards, and verification procedures provides an additional layer of assurance for auditors and procurement officers.
Bringing the pillars together – a holistic assessment framework
When evaluating a cybersecurity provider, organizations should not treat the four pillars as isolated check‑boxes but as interdependent elements of a comprehensive trust model. Compliance establishes the legal permissibility of the solution; risk mitigation demonstrates the provider’s ability to manage emerging threats; transparency offers the evidence base that regulators and customers can audit; and security‑by‑design ensures that the solution is resilient from its inception.
A provider that can present documented CRA certification, NIS 2 compliance, a proven risk-mitigation pipeline, transparency centers, and a documented secure software development lifecycle satisfies the full spectrum of requirements that European public and private entities face today. Such a provider is not merely “compliant” but demonstrably a trustworthy contributor to the digital and cybersecurity ecosystem in Europe, capable of supporting the EU’s broader objectives of digital sovereignty and cyber‑resilience. By applying this four‑pillar framework, decision‑makers can move beyond superficial marketing promises and make evidence‑based selections that align with both regulatory mandates and strategic security goals.
