Welcome. A software product can be assessed in two ways. The first is to ask whether it works: it does what it promises, does not crash, and its users like it. The second is to ask what happens when someone tries to make it do what it must not: read other people's data, open a door that should have stayed closed, become the point through which someone gets into a customer's network. For decades the market rewarded almost only the first way, and the second was treated as a cost to put off until after release.

That "afterwards" is coming to an end. The Cyber Resilience Act, Regulation (EU) 2024/2847, makes security a requirement for selling a product with digital elements in the Union, as electrical safety has long been: essential requirements, conformity assessment, CE marking, technical documentation, obligations that continue for the whole support period. The Regulation has been in force since 10 December 2024 and part of it already applies: from 11 September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents affecting their products. The rest applies from 11 December 2027.

This path teaches you to do the work those obligations presuppose, and it is the same work the technical references have been describing for years: the NIST Secure Software Development Framework, the OWASP projects, MITRE's classification of software weaknesses. It is not a law course for developers nor a catalogue of tools: it is a method, applied to every phase in which a decision makes the product more or less defensible.

A single question runs through the whole path, the same one an attentive customer, a market surveillance authority or an attacker would ask: how do you know it is secure, and how do you prove it? Each module produces a piece of the answer - the risk assessment, the requirements, the choices in the code, the software bill of materials, the evidence, the vulnerability policy - and in the end those pieces are the technical documentation the Regulation requires.

The exercises follow a single case: Lariotech, an Italian manufacturer of connected locks with an app and a cloud service, grappling with its first product to bring into compliance. A constructed case, but with the real problems of people developing today.

Path objectives

By the end of the path you will be able to:

• explain why security flaws reach production and what security by design means, and place a product and an organisation within the framework of the Cyber Resilience Act, NIS2 and liability for defective products (Module 1);
• carry out and document a cybersecurity risk assessment of a product and turn it into verifiable security requirements (Module 2);
• model the threats to a system with data flow diagrams and STRIDE, and derive countermeasures and secure by default settings from them (Module 2);
• recognise and prevent in code the most frequent and most severe classes of defects, using the OWASP and CWE rankings correctly, and carry out a security-focused code review (Module 3);
• governing third-party components: due diligence, composition analysis, software bill of materials, build and pipeline integrity (Module 4);
• choose and combine verification techniques knowing what each one does not find, and build a pipeline with sustainable release gates and retained evidence (Module 5);
• manage vulnerabilities after release - coordinated disclosure, triage, fixing, advisories, updates - and meet the timing and content requirements of the Cyber Resilience Act's mandatory reporting (Module 6).

Who it is for and prerequisites

The path is aimed at those who design, write, verify or sell software: developers and project leads, architects, product and quality managers, DevOps and platform engineers, security managers in companies that produce software, applications or connected devices. It is also useful to those who, in an essential or important entity under NIS2, have to assess the software they buy or develop in-house.

Prerequisites. You need to be able to read code and know broadly how a web application or a network service works; the examples are short and commented, and do not require any particular language. The basic concepts of risk and threat are provided by Fondamenti di Information Security. Those who need to govern compliance rather than write code will also find the Cyber Resilience Act, from the governance side, in Module 9 of Cybersecurity Governance, Risk & Compliance; incident management in general is covered by Gestione e risposta agli incidenti.

How it works

The path runs entirely online, asynchronously: you can study whenever you like, at your own pace, from any device. The estimated total duration is 26 hours, to be spread out within the completion deadline indicated further on.

Each module is organised into four lessons and two tests:

1. Lesson. A reasoned treatment of the topic, with diagrams, examples and concrete cases.
2. Test. Closed answer questions on the whole module. Passing requires at least 70%; attempts are unlimited and the best mark counts. At the end of each attempt you get a precise explanation of every answer, including the correct ones.
3. Exercise. A case to work through by making choices: each decision opens a different route and the outcome depends on what you chose, with an explanation of what would have happened otherwise. Assessment is automatic and you can retake it as many times as you like.

Progression. The 6 modules are taken in sequence: each module unlocks only after you have passed the test of the previous module. The exercises do not block progress, but they are an integral part of the path and of the overall assessment.

Final test and certificate

Once you have passed the tests of all modules, the final test unlocks: 30 questions drawn at random from the topics of the whole path, with the same 70% threshold. You have three attempts, at least one week apart: if none reaches the threshold, the path restarts from the first module. When you pass you obtain the path certificate, downloadable as a PDF, with a unique code that allows its authenticity to be verified.

Caveat

The content is updated to October 2026. Three specific caveats for this subject.

The first, on the regulation. The Cyber Resilience Act applies in full from 11 December 2027 and many of its implementing instruments - harmonised standards, Commission guidelines, the Italian alignment decree - are still in progress. For each one the path states what exists and what does not, with the date of the check; before a conformity decision, check the current status. The path does not constitute legal advice.

The second, on standards. The rankings and frameworks cited change edition: always cite the edition, and read each for what it measures. A ranking of weaknesses is not a list of requirements, and no checklist on its own makes a product compliant.

The third, on examples. Code snippets are there to show a defect and its fix, not to be copied into production; the path names categories of tools and not products. The exercise scenarios are constructed; the real-world cases are verified at source and linked.

Support

In the Announcements forum you will find the instructor's communications. For questions about the content or the exercises, use the channels indicated by your training contact.