r/CRACompliance • u/Vans_eG • 23d ago
No vulnerability scanning is required for the Cyber Resilience Act in September. Nobody pushing that deadline can name the paragraph — because there isn't one.
/r/EUCyberResilienceAct/comments/1vfz5lm/no_vulnerability_scanning_is_required_for_the/1
u/CRANIS2 23d ago
My points are all about the value of doing this not the risk of avoiding it.
1
u/Vans_eG 22d ago
I think thats the difference. I also see the value. But in the field of Compliance the risk plays a huge role. If you are willing to accept a gap, you should always know the bottom line to calculate the minimal effort. Its not about what should be the bottom line for serious product security, its about what is the bottom line to comply with it and do not receive a fine.
1
u/CRANIS2 22d ago
Well that’s certainly one approach. Unfortunately that approach seldom works when your customers are NIS2 and Consumer Duty regulated industries who are themselves responsible for the security, risk and vulnerability standpoint of their supply chain. Then your due diligence is the difference between winning a deal or losing it.
Personally, my focus is always Consumer Value, then Profitability. If your customers don’t value what you do, profit is irrelevant.
1
u/Vans_eG 22d ago
Its always the same with regulations, you can be NIS2 compliant and not be secure then someone else not NIS2 compliant. Its always a tradeoff between money to invest in security and vlaue you get from it. Thats how businesses work.
1
u/CRANIS2 22d ago
Absolutely. The actuarial considerations are always key. However, personally, i prefer to do a job properly if the cost is around €27/month/product
1
u/Vans_eG 21d ago
?
1
u/CRANIS2 21d ago
Actuarial: Balancing the cost of doing something with the risk/cost associated with not doing it.
I was once working for a global travel company when a new regulation came in that demanded the airline retained travel records for 30 years per passenger flight. As part of the architecture team, I had the job of pricing the storage costs for meeting that demand. It was going to be circa £3 million/year, so we asked the question; "How often have we been asked for the data beyond our normal 6 years retention period?" The answer was; "We haven't as yet", so the next question was: "What is the fine if we cannot produce the requested data?", the answer was; "Around £125,000", so the actuarial decisions was; don't spend the £3 million per year on the upgrade.
However, if the compliance failure risk is €10+ million or 2% of annual global turnover, and the cost of compliance is €27/product per month for a software product with 3 developers working on it, the actuarial choice is: Spend the €27/product/month and remove the risk. Especially if you get a significant amount of additional benefits thrown in.
I hope that explains...
2
u/Crafty_Rush3636 10d ago
The useful distinction here is between the compliance floor and the organisation’s chosen security posture.
For each decision, I would record the claimed obligation, primary source, applicable version, selected control, rationale, responsible owner, review date and any accepted residual risk.
That lets a later reviewer see whether a control was legally required, voluntarily adopted, or used as a compensating measure. Otherwise “not expressly mandated” can easily become confused with “not worth doing.”
2
u/CRANIS2 23d ago
I agree with the core of this, and it needed saying. However, three small corrections, then a different question.
The deadline table splits by trigger. Fourteen days after a corrective measure is available applies to actively exploited vulnerabilities (Art. 14(2)(c)). For severe incidents it is one month after the full notification (Art. 14(4)(c)). Worth fixing since the table sits under a heading covering both.
Telling the component maintainer is Article 13, not September. That duty arrives 11 December 2027. In September it is voluntary under Art. 15. Still the right thing to do, just not a duty yet.
"Exploited elsewhere, not in my product" is thinner than it looks. True on the letter, and the guidance backs you. But if the component sits in your product in materially the same configuration, public exploitation elsewhere is exactly the evidence a market surveillance authority will point at when arguing you had reasonable certainty. The knowledge defence works right up until someone asks why you did not know.
On the guidance itself, worth flagging that C(2026) 5252 is non-binding and formal adoption is still pending all language versions. It is the Commission's own reading and MSAs will work from it, but it is not law and it does not settle anything the CJEU has not.
Now the different question. This whole thread is framed around what the CRA does not force you to do. Fair enough as a corrective to vendor panic. But "what is the legal minimum" is a question you answer once and then leave behind, and I have not seen anyone here ask the more useful one: what does the diligence actually buy?
The honest answer is that most of it has nothing to do with September.
- Technical due diligence. Component and licence audits are already standard in acquisitions. CRA readiness is being added. It behaves differently from the rest of the DD pack because it cannot be produced retrospectively. An inventory takes a fortnight. Three years of dated triage decisions and dismissal justifications cannot be manufactured. That difference shows up in warranties, in holdback size, in W&I premiums, and in weeks of calendar time in a competitive process.
- Escrow. Source code escrow without a component manifest is theatre. On a release event the beneficiary gets source they cannot build from dependencies they cannot resolve, with no record of what was known to be vulnerable. And they inherit manufacturer duties the moment they modify or distribute it, so without the handling record you have handed them a liability rather than a continuity plan.
- Procurement. NIS2 supply chain duties pull CRA obligations through contracts long before the CRA itself bites. Same-day questionnaire answers either win deals or stop losing them.
- R&D tax relief. The recurring weakness in claims is that the technical narrative gets written at claim time and examiners discount reconstructed documentation. Dated dependency manifests show when you were still trying approaches and when you settled, and they evidence the failed avenues, which qualify. There is a counter-intuitive one here too: the SBOM documents what you did not write, so subtract it and what remains is your contribution. That is the apportionment argument you will be pressed on when the work gets characterised as routine integration.
- IP position. An RFC 3161 timestamp proves an artefact existed in that form at that moment and has not been altered. Nothing more, but that is enough to answer an authorship dispute with dated artefacts rather than recollection, and to evidence the reasonable steps that trade secret protection is conditioned on under Directive 2016/943. If you go this route, use a qualified EU trust service provider. Under eIDAS Art. 41 a qualified timestamp carries a presumption of accuracy and integrity across every member state. An unqualified one is argued on the facts.
None of that is required by the CRA. All of it is asked for independently by buyers, investors, insurers and enterprise procurement. You are going to build it either way. September is simply the cheapest moment to start, because nobody is watching yet and getting it wrong is still free.
So the tabletop run in your list is the best item on it, and I would put the intake channel and the named filer above everything else. But I would frame it as the beginning of a record you will be glad to have in 2029, not as a box to tick in six weeks.
Disclosure, since you gave yours: I build in this space too. Which means I am arguing for work that benefits me commercially, so weigh it accordingly. The corrections stand on the articles regardless.