IoT Cyber Resilience Act readiness: security reporting, release evidence, and verified fixes

Over the last week I have been tightening one part of the Combotto offer that more IoT teams are going to care about soon:

What happens when someone needs to report a serious security issue affecting a connected product, and what the supplier can actually do with that report next.

This is not a flashy new product.

It is practical readiness work:

• A public page that tells people how to report an issue.
• A small machine-readable contact file that points automated tools and security researchers to the right place.
• A public page where future security notices can be published.
• A stronger internal workflow around the reference IoT Gateway so one issue can be reviewed, scoped, fixed, verified, and communicated more cleanly.

The reason this matters now is simple:

the EU Cyber Resilience Act starts applying reporting obligations for actively exploited vulnerabilities and severe incidents on September 11, 2026.

For teams shipping connected products, that date is close enough that “we should sort out the reporting path later” is no longer a comfortable answer.

This post is a higher-level explanation of what I shipped, why I shipped it now, and why I think this belongs inside Combotto’s audit-first consulting path.

Why more teams are being pushed in this direction

This is not only a technical preference.

It is increasingly a business and compliance issue.

Enterprise buyers, partners, and security reviewers are asking harder questions than they used to:

• How do you accept and handle security reports?
• Which versions are affected if a serious issue is found?
• What third-party components are inside the release?
• How do you verify that a fix really made it into the shipped product?
• How fast can you prepare customer or regulator communication if the issue is serious?

In Europe, the Cyber Resilience Act raises the stakes further by pushing manufacturers of products with digital elements toward stronger secure-by-design practices, clearer vulnerability handling, and formal reporting obligations.1

That is one reason I have been leaning further into a more disciplined secure software development lifecycle, stronger release evidence, and more formal review and verification steps instead of treating security as a loose collection of best efforts.2

This is also where the Combotto offer fits.

Combotto can help teams:

• Audit the current product and release path to expose the biggest gaps first.
• Harden the highest-impact weak spots in a focused sprint.
• Keep the workflow credible over time through repeat reviews, evidence refresh, and release-level follow-up.

Why I shipped the public reporting surface before the first advisory

If the reporting path only gets created when the first serious issue lands, the team is already behind.

That is why I wanted the basics live before they were urgently needed.

The point of shipping /security, /security/advisories, and /.well-known/security.txt now is to make three things clearer:

• Make reporting predictable before pressure lands.
• Make the future publication path obvious before the first public notice needs a home.
• Make the contact route discoverable without turning the site into generic security marketing.

The setup is intentionally low-profile.

It is practical operating guidance for one concrete product path, not a claim that Combotto now runs a large outsourced security response function for every kind of software company.

Larger vendors often describe this kind of product-security response discipline as a PSIRT, short for Product Security Incident Response Team.3 Combotto is deliberately taking a smaller, manual-first path here: build the real workflow first, keep it honest, and avoid pretending a full-scale program already exists.

What is live now on combotto.io

The website now carries the basic public reporting surface for the reference IoT Gateway path:

• /security explains what is in scope, what kind of evidence is useful, and how reports should be sent.
• /.well-known/security.txt is a small standard file that points people and automated tools to the security contact route.
• /security/advisories is the public page where future security notices can be published, even though no notice is published yet.

That “nothing published yet” state is intentional.

The point of the page is not to look busy today. The point is to avoid making up the publication process later under pressure.

The reference IoT Gateway now has better release evidence behind it

The public website surface would be weak on its own if the product path behind it still had no real release discipline.

That is the other part that changed.

The reference IoT Gateway now has clearer answers around:

• Where reports should go.
• Which release line is currently supported.
• How future public notices will be named and tracked.
• How changes to trusted certificates and identities should be recorded.

It also now has a stronger release-evidence bundle.

In plain English, that means a release candidate can now be packaged with supporting evidence such as:

• A software bill of materials, which is simply a structured inventory of what dependencies are in the build.
• Dependency-audit output showing known issues that need review.
• Metadata about the build, the tools used, and the source tree that produced it.

In the Rust ecosystem, tools such as cargo-cyclonedx and cargo audit are useful for exactly this kind of release evidence and dependency review.45

That is a much stronger answer than “we should probably gather release evidence later if something goes wrong.”

It gives a better foundation for release decisions, customer explanation, and later reporting work if a serious issue needs to be handled.

The review workflow is also getting more concrete

The other improvement is the workflow around how one serious issue gets handled after it has been identified.

Instead of scattered notes and one-off coordination, the workflow can now carry one issue through a clearer sequence:

intake -> validated -> prioritized -> remediation_planned -> remediated -> verified -> disclosure_ready -> closed

The useful part is not the state names themselves.

The useful part is that one issue can now keep track of:

• Release-impact answers per release line.
• Owners and due dates.
• What evidence was used to review the issue.
• What was decided.
• What was fixed.
• What still needs to be communicated.

It can also produce draft outputs from that same review path, for example:

• An internal draft notice.
• Draft reporting material.
• The supporting context needed to explain what was affected and what changed.

That matters because it reduces the chance that engineering, release, and communication each invent their own version of the truth.

For a small team, that kind of discipline matters more than a fancy portal.

One worked example now ties the story together

This is also not just a policy exercise.

I now have one worked vulnerability example that ties the path together from review to communication planning.

• A case record.
• A release-impact answer.
• A draft public notice.
• Draft reporting material.
• A short retrospective on what should stay manual and what may deserve better tooling later.

That matters because honest readiness is not about publishing the most polished policy page.

It is about being able to take one meaningful issue, move it through review and decision-making, tie it to a release answer, and prepare the communication path without losing the thread.

Why this belongs inside the Audit -> Sprint -> Retainer offer

I do not want this work to turn into a detached “compliance service” story.

The more useful framing is that it strengthens the existing Combotto consulting path:

• An Audit can now surface whether the team actually has a credible path for handling a serious vulnerability: reporting intake, release answers, evidence capture, fix verification, and communication discipline.
• A Hardening Sprint can then fix the highest-impact gaps first: public reporting path, release checklist, dependency inventory, evidence packaging, version-impact handling, and remediation verification.
• A Retainer can keep that posture from drifting by reviewing open issues, weak spots in the workflow, and readiness gaps before the next customer review or external deadline forces the issue.

In other words, this is not a separate business line.

It is a stronger answer to a question more teams are going to face:

If a serious vulnerability lands on your connected product path tomorrow, can you prove what is affected, what is supported, what changed, what was fixed, and what needs to be reported?

What this does not mean

This does not mean Combotto now offers:

• A full outsourced security response team.
• Regulator-submission automation.
• A mature advisory platform.
• Finished CRA compliance automation.

The current shape is deliberately narrower and more honest:

• Public intake is live.
• The future public notice page is live.
• The reference IoT Gateway now has stronger release evidence, including a dependency inventory and audit trail.
• The review workflow can carry one issue into draft-ready outputs.
• Reportability and final disclosure decisions remain explicitly manual.

That is the right level of truth for this phase.

Why I think this is worth building now

For connected products, the hard part is rarely writing one policy page.

The hard part is building a path that stays coherent under pressure:

• One intake path.
• One case record.
• One release-impact answer.
• One remediation and verification trail.
• One place where future public notices can live.

That is the kind of operational discipline I want Combotto to help teams build.

If your team is already thinking about upcoming customer scrutiny, supplier-side reporting expectations, or CRA readiness before September 11, 2026, this is exactly the kind of work that should be made concrete before the first serious case arrives.

If that pressure is already present, start with the IoT audit page, inspect the gateway hardening reference, or use the contact route to scope the smallest credible starting point.

Footnotes and further reading

1. Cyber Resilience Act: The European Commission has a practical summary of the CRA reporting obligations, including the September 11, 2026 start date, early warning, and follow-up timing. See Cyber Resilience Act reporting obligations. For the legal text itself, see Regulation (EU) 2024/2847 on EUR-Lex.

2. SSDF: NIST’s Secure Software Development Framework is a useful reference for turning secure development into repeatable practices instead of good intentions. See NIST SP 800-218 and the SSDF project page.

3. PSIRT background: If you want the broader context for product-security response work, the FIRST PSIRT Services Framework is a helpful reference.

4. SBOM and CycloneDX: For background on software bills of materials and the CycloneDX format, see OWASP CycloneDX. For the Rust cargo plugin used to generate that kind of output, see cargo-cyclonedx on docs.rs and the CycloneDX Rust Cargo project on GitHub.

5. Rust dependency auditing: For the Rust dependency-audit tool referenced here, see cargo-audit on docs.rs and the Rust tool page for cargo-audit.