Cybersecurity.
A matter of posture.

CRA and NIS2 regulatory compliance.

M4SS is an important NIS2 entity registered with ACN (Agenzia per la Cybersicurezza Nazionale) and a producer of hardware subject to the CRA (Cyber Resilience Act). That means we calibrate compliance for ourselves first. From the resulting experience, we create value for clients.

Problem

The Cyber Resilience Act (EU Regulation 2024/2847) is in force: full obligations kick in on December 11, 2027, while vulnerability reporting obligations already apply from September 11, 2026. The NIS2 Directive is operational, and important entities must put in place governance, supply chain, incident management, and documentation that can stand up to oversight bodies. For those starting now, the required documentation is extensive. For those who tried with generalist consultants, the result is often a Technical File that collapses at the first question from the notified body.

Solution

M4SS is going through this process itself. The CDM-CRA project is bringing our Communication Data Module to full CRA compliance before commercialization: gap analysis, OTA pentest, SBOM, security policy, Technical File, Declaration of Conformity, operational PSIRT. We sell the experience, not the theory. For NIS2 entities we bring the same approach: ACN registration and compliance, risk governance, supply chain, incident handling, documentation that holds up to audit. The living proof is the CDM-CRA itself, which produces the deliverables in real time that we reapply to clients.

• Technical File CRA complete: risk assessment, security plan, vulnerability management throughout the lifecycle.
• Declaration of Conformity and CE marking management.
• PSIRT operational: policy, disclosure channels, patch management processes.
• NIS2 end-to-end: ACN registration, governance, supply chain, business continuity, incident reporting, SBOM (CycloneDX/SPDX).

Vulnerability Assessment and Penetration Testing.

Problem

NIS2 entities must periodically attest the security of their systems. Hardware distributors and manufacturers subject to the Cyber Resilience Act (CRA) must demonstrate a continuous vulnerability handling process. A raw technical report, consisting only of CVEs and CVSS scores, isn't enough anymore: the auditor asks which NIS2 obligation each finding addresses, which CRA article is in play, how much regulatory risk remains after remediation.

Solution

M4SS conducts Vulnerability Assessment and Penetration Testing on web applications, APIs, cloud infrastructures, IIoT and embedded devices, OT/SCADA environments, and software supply chains. We use industry-standard tools (Burp Suite, ZAP, Metasploit, Nmap; specific OT/SCADA tooling where needed), with a taxonomy consistent with CWE and MITRE ATT&CK. What differentiates our report is a proprietary mapping tool: every vulnerability found is connected to the NIS2 obligation and CRA article it impacts, with a Regulatory Risk Score for prioritization. When the pentest ends, the client doesn't receive a technical report to translate: they receive a dossier already prepared for the audit.

• Broad scope: web, API, cloud, IIoT/embedded, OT/SCADA, software supply chain.
• Taxonomy: CWE and MITRE ATT&CK.
• Map CVE → NIS2 control → CRA article, with a Regulatory Risk Score per item.
• Three-tier reporting: executive summary, technical detail, reproducibility.

Software supply chain security Rust.

Problem

Modern software is a chain of dependencies: a vulnerability in a transitive library becomes a vulnerability in your product. The Cyber Resilience Act references this in Art. 13, NIS2 in the controls annex. A superficial supply chain audit, done with just a cargo audit and a PDF, isn't enough. You need to know which crates are unmaintained, which have unverifiable supply chains, which have unreviewed unsafe code, which are being deprecated.

Solution

M4SS audits the Rust supply chain from within the community that produces it. Six published RustSec advisories, responsible disclosure with fixes merged upstream, direct contributions to the core of the ecosystem. M4SS is a maintainer of lettre (the reference Rust SMTP library) and co-maintainer of rust-postgres (the reference PostgreSQL® client). When we audit a Rust codebase for a client, we do it with the same tools and standards we use to contribute to the ecosystem. (The detail of the upstream work, with numbers and projects, is in Activities › Open Source.)

• Dependency audit with cargo-deny, integrated with the RustSec database we contribute to directly.
• Crate reproducibility with cargo-goggles, an M4SS open source tool.
• Code audit targeted at unsafe modules, cryptographic code, network parsers.
• Rust adoption for new memory-safe development: strategy, training, continuous review.

Red Team.

Problem

Want to know if you can withstand a real attack? We simulate the real attacker. Not the bug-hunter on the perimeter. NIS2 entities and hardware distributors and manufacturers subject to the Cyber Resilience Act (CRA) must demonstrate they can withstand a real attack scenario, not just that they have no known bugs. A Vulnerability Assessment answers one question: what bugs are there. A Red Team answers a different question: if someone really wanted to get in, could they?

Solution

M4SS conducts complete Red Teaming campaigns, across all phases: reconnaissance (OSINT), building the initial access vector, lateral movement, persistence, exfiltration, evasion of defensive controls. On agreed scope, with written rules of engagement and a clear chain of custody for every piece of evidence collected. When it makes sense and the client authorizes it, we also include controlled social engineering (phishing, pretexting). We operate in coordination with your Blue Team if present, in black-box mode if not. Methodology inspired by TIBER-EU as a process reference; taxonomy and reporting based on MITRE ATT&CK.

• All phases of the kill chain: OSINT, initial access, lateral movement, persistence, exfiltration, evasion.
• TIBER-EU-inspired methodology + MITRE ATT&CK reporting.
• Explicit rules of engagement: written authorizations, closed scope, exfiltration only simulated.
• Mapping of outcomes to NIS2 and CRA controls where applicable.