Automotive Cybersecurity
UN R155, ISO/SAE 21434 and the Auto-ISAC's Automotive Threat Matrix — how attacker behaviour against the vehicle is described, rated in the TARA and demonstrated in the pentest.
Secure Software & Product Development
Secure software development from the first line of code to the field: secure coding, a secure development lifecycle (SSDLC), pipeline and supply chain security, and product security by product type — CRA, IEC 62443, UN R155/R156 with ISO/SAE 21434, MDR/IVDR.
Secure software and product development means building security into a product demonstrably across its lifecycle — from design and code to build, release and vulnerability handling in the field. The applicable rules depend on the product type. Hardware and software with digital elements, including industrial components, fall under the Cyber Resilience Act (CRA); for industrial components, the IEC 62443 series is the recognised state of the art, and from 20 January 2027 machinery is additionally subject to the Machinery Regulation. Vehicles need UN R155 and R156 for type approval, usually implemented with ISO/SAE 21434. Medical devices are governed by the Medical Device Regulation (MDR) and the IVDR, with IEC 81001-5-1 as the reference point. Type-approved vehicles and medical devices are excluded from the CRA because sector-specific law applies.
Topics & knowledge pages
Each topic leads to a dedicated knowledge page with deep dives, practical guides and the matching services.
Secure development
Secure coding, SSDLC implementation and developer enablement — security as part of the craft, not an afterthought.
Pipeline & supply chain
Harden build chains, control dependencies, sign artifacts — from SBOM and SLSA to AI-powered pipeline security.
Product security by product type
The product type determines which cybersecurity requirements apply. The four product types at a glance — with scope, key standards and deadlines; where sector-specific legislation applies, the CRA steps back.
CRA — products with digital elements
Cross-sector EU obligations for manufacturers of connected hardware and software — from planning and development to vulnerability handling across the entire lifecycle.
- Products
- Hardware and software with digital elements — from smart home devices, routers and operating systems to apps
- Rules & standards
- CRA; harmonised standards (EN 40000 and ETSI EN 304 series) in progress, none in the Official Journal yet; ENISA reporting platform
- Key dates
- In force 10 Dec 2024 · notified body rules 11 Jun 2026 · reporting obligations 11 Sep 2026 · full application 11 Dec 2027
IEC 62443 — industrial automation & OT
International series of standards for secure development processes, components and systems in industrial automation — voluntary, but the recognised state of the art and the basis for future harmonised CRA standards.
- Products
- Industrial automation (OT) components and systems, controllers and machinery — for manufacturers, integrators and asset owners
- Rules & standards
- IEC 62443-4-1 (development process), -4-2 (components), -3-3 (systems), -2-1 (asset owners); CRA; Machinery Regulation
- Key dates
- Machinery Regulation from 20 Jan 2027 · alignment of EN IEC 62443-4-1/-4-2 with the CRA in progress
Vehicles — UN R155/R156 & ISO/SAE 21434
Cybersecurity is a prerequisite for type approval: vehicle manufacturers need a certified cybersecurity management system (CSMS) and a software update management system (SUMS).
- Products
- Cars, buses and trucks (M, N), trailers (O) for software updates; new two-/three-wheeler and quad types (L) from 11 Dec 2027
- Rules & standards
- UN R155 (CSMS), UN R156 (software updates), ISO/SAE 21434 as the engineering standard; excluded from the CRA
- Key dates
- R155: new types since 6 Jul 2022, all new registrations since 7 Jul 2024 (large series) · R156: existing types since 7 Jul 2026
Medical devices — MDR & IVDR
IT security is part of the general safety and performance requirements of the MDR and IVDR — to be demonstrated before placing on the market and maintained through post-market surveillance and maintenance in the field.
- Products
- Medical devices and in vitro diagnostic devices, including software as a medical device; excluded from the CRA
- Rules & standards
- MDR/IVDR, MDCG 2019-16 Rev. 1, IEC 81001-5-1 (recognised reference, not harmonised), AI Act for AI-enabled medical devices, Data Act for connected products
- Key dates
- MDR since 26 May 2021 · IVDR since 26 May 2022 · AI Act high-risk obligations for AI medical devices from 2 Aug 2028
Free self-assessments & tools
Where do you stand? OWASP-based self-assessments (SAMM, ISVS, SCVS) and VamiAppSec — our LLM-powered platform for a secure SDLC and product-security compliance, with VamiDAST fully integrated for AI-powered DAST.
Consulting · AI Code Security
When rules are no longer enough: code security in the age of AI
Rule-based scanners reliably find syntax flaws. Broken authorization, business logic and wrongly assumed permissions have no signature at all. We bring rules, AI reasoning and exploit validation into an order your team can operate.
- Layer 1–3 scanning architecture
- Introduce and calibrate AI SAST
- Exploit validation
- Ownership & remediation
- Evidence for CRA and NIS2
Explore AI Code Security
A consulting service — the knowledge pages above stay freely accessible.
Deep Dives
In-depth knowledge pages on the topics that currently raise the most questions — with verified sources and concrete measures.
Clinical AI Risk Management
How hospitals, practices and laboratories operate AI systems securely: deployer duties under the AI Act and their interplay with the MDR, shared responsibility with the provider, a threat model for medical AI, risk assessment and robust evidence.
View knowledge pageMedical Device Maintenance
How manufacturers and hospitals keep connected medical devices secure in the field: with an inventory and SBOM, clinically grounded triage, patches as controlled changes, coordinated vulnerability disclosure and aligned reporting channels.
View knowledge pageData Act & Medical Devices
How manufacturers can design the legally required access to device data so that patient safety, health data and trade secrets remain protected – with a threat model, penetration testing and an integrated management system.
View knowledge pageSlopsquatting & coding agents
AI models suggest packages that do not exist — and attackers can register exactly those names. Coding agents with terminal access install whatever they consider right. This deep dive connects typosquatting and slopsquatting in npm and PyPI with a security model for coding agents and their harness: attack chain, five protection layers, obligations under the CRA, NIS2 and DORA, a self-assessment and a CISO whitepaper (in German).
View knowledge pageAutomotive Threat Matrix
How the Auto-ISAC matrix describes attacker behaviour against the vehicle – and how it gives the TARA under ISO/SAE 21434, the evidence under UN R155, the OWASP testing catalogues and the Vehicle SOC a common language.
View knowledge pageSecure Coding
How to prevent vulnerabilities systematically: the current landscape of the CWE Top 25 and OWASP Top 10:2025, ASVS 5.0 as a requirements framework, and the practices that make the difference in day-to-day development.
View knowledge pageSAST
Static code analysis is the most densely cross-referenced control point in the secure development lifecycle – and the tool with the greatest frustration potential. What SAST delivers technically, where its limits are proven, which standards require it, and what AI is changing about it right now.
View knowledge pageAI SAST
Language models triage findings, reason semantically across function boundaries and find real zero-days. What of that is evidenced, which tools exist in 2026 and where the new limits and risks lie — with sources instead of marketing.
View knowledge pageSecure SDLC
How to systematically integrate security into every phase of software development – with the NIST SSDF as a practice catalog, OWASP SAMM as a maturity model, and security gates from requirements all the way to operations.
View knowledge pageOWASP for Dev Teams
Top 10, ASVS, Cheat Sheet Series, Developer Guide, WSTG, SAMM and tools such as Dependency-Track and ZAP: what each project delivers – and how these building blocks connect into an end-to-end process in everyday development work.
View knowledge pageThreat Modeling
How to identify security risks as early as the design phase using the Four Question Framework, STRIDE, PASTA and attack trees – and how to anchor threat modeling permanently in the SDLC and agile teams.
View knowledge pageSecurity Champions
How to embed security expertise in your development teams for the long term – from selecting suitable champions through time budgets and community to measuring success based on the OWASP guide and SAMM.
View knowledge pageSBOM Management
How to generate, distribute and operationalize software bills of materials (SBOMs) in a standards-compliant way – from format selection and build integration to continuous vulnerability correlation.
View knowledge pageCI/CD Pipeline Security
Why build and deployment pipelines are among the most critical systems in your IT estate – and how to secure them in a structured way along the OWASP Top 10 CI/CD Security Risks and SLSA.
View knowledge pageProduct Security
Why the security of connected products requires dedicated standards, processes and organizational structures – from ISO/SAE 21434 through IEC 62443 and EN 18031 to the PSIRT.
View knowledge pageWhitepapers for download
Each whitepaper has its own page with details and a direct download form.
EU CRAEU Cyber Resilience Act — Practical guide for digital productsGo to whitepaper page 
CI/CD SecurityCI/CD Pipeline Security: How Attackers Take Over Your Pipeline — and How You Take It BackGo to whitepaper page 
DevSecOpsOWASP Top 10 CI/CD Security Risks — Practical Guide with Compliance CrosswalkGo to whitepaper page 
Secure CodingSecure Coding in the AI Era: The CWE Top 25 (2025) and Secure-by-DesignGo to whitepaper page 
AI & CI/CD SecurityAI-Powered Security in the CI/CD PipelineGo to whitepaper page 
Automotive CybersecurityAutomotive Threat Matrix — ATT&CK for VehiclesGo to whitepaper page 
Software supply chain / AI agentsSlopsquatting & Coding-Agenten für CISOs — securing the AI software supply chainGo to whitepaper page Latest news on this topic area
All newsExpert article in mt|medizintechnik: maintaining connected medical devicesIn issue 4.2026 of the trade journal mt|medizintechnik, Valeri Milke explains why vulnerability and patch management for connected medical devices are a matter of patient safety. Our new knowledge page summarises his key points and explores them in depth.Expert article in mt|medizintechnik: risk management for AI systems in clinical settingsIn issue 2.2026 of the trade journal mt|medizintechnik, Valeri Milke shows how hospitals can use risk management to safeguard their use of AI systems. Our new knowledge page summarises his key points, updates them and explores them in depth.
FAQ
Frequently asked questions on product security by product type
Which rules apply to which product — and where does the Cyber Resilience Act not apply? Short answers to questions that manufacturers and regulatory affairs managers ask most often.
Does the Cyber Resilience Act apply to medical devices?
No. Products covered by the MDR or the IVDR are excluded from the Cyber Resilience Act. Their cybersecurity is governed by the two medical device regulations, with the MDCG 2019-16 Rev. 1 guidance and the IEC 81001-5-1 standard, which has not yet been harmonised, as reference points. Software and devices without a medical intended purpose — general hospital IT, for example — may well fall under the CRA, however.
Does the CRA apply to cars and vehicle components?
Not to type-approved cars, buses, trucks and trailers: they fall under EU type approval, which governs cybersecurity through UN R155 and software updates through UN R156. As a rule, the exclusion also covers systems and components type-approved for such vehicles. Since 2025, a delegated act has additionally excluded two- and three-wheelers and quads; for new types in this category, UN R155 applies from 11 December 2027. Aftermarket products, charging equipment or apps outside type approval, by contrast, may fall under the CRA. Pedal cycles of category L1e also remain within the CRA.
Is IEC 62443 mandatory?
No. IEC 62443 is an international series of standards, not a law. It is, however, regarded as the state of the art for industrial components and is currently being adapted for the CRA — for example through amendments to EN IEC 62443-4-1 and -4-2 and product-specific profiles. The presumption that the legal requirements are met (presumption of conformity) only arises once a harmonised version is cited in the Official Journal of the EU; as of October 2026, this is not the case.
When does the CRA reporting obligation apply, and where do manufacturers report?
Since 11 September 2026, manufacturers have had to report actively exploited vulnerabilities and severe incidents to the competent national CSIRT via ENISA’s Single Reporting Platform. The deadlines: an early warning within 24 hours, a notification within 72 hours and a final report no later than 14 days after a corrective measure becomes available — for incidents, within one month of the notification. The obligation also covers products placed on the market before the cut-off date.
What is the difference between UN R155 and ISO/SAE 21434?
UN R155 is a binding type-approval regulation: without a certified cybersecurity management system (CSMS), a vehicle type will not be approved. ISO/SAE 21434, by contrast, is the engineering standard that manufacturers and suppliers use to implement the required processes, such as threat analysis and risk assessment (TARA). The standard is not legally mandated, but it is the usual way to demonstrate compliance; manufacturers cover gaps such as the R155 threat catalogue separately.
Are there harmonised standards for the CRA yet?
Not yet. The Commission’s standardisation request covers 41 horizontal and product-specific standards. Under a draft amendment that had not been adopted as of October 2026, the first horizontal standards are due by the end of October 2026 and product-specific ones by the end of December 2026. As long as no version is cited in the Official Journal, there is no presumption of conformity: manufacturers must substantiate compliance with the requirements themselves, and important products of class I then require a notified body.
Make security part of your development
In an initial consultation, we assess your SSDLC maturity — and show you which measures in your pipeline, code and product approval offer the greatest leverage.