FIELD
NOTES.

We didn’t set out to build a SaaS product.

We set out to answer a question that kept coming up in our conversations with EU manufacturers: “We know the Cyber Resilience Act is coming. We know we need to do something about vulnerability disclosure. But where do we actually start?”

The honest answer, every time, was: “It’s more complicated than it should be.” That bothered us enough to do something about it.

The problem we kept seeing

The EU Cyber Resilience Act (CRA) introduces two distinct compliance deadlines that tend to get conflated, and that conflation is causing real harm to how companies are planning.

The first deadline is 11 September 2026. From that date, Article 14 of the CRA is enforceable. Every manufacturer selling products with digital elements into the EU market must have a process in place to report actively exploited vulnerabilities to ENISA: a 24-hour early warning, a 72-hour full notification, and a 14-day final report. This is not optional, it is not limited to large companies, and it applies to products already on the market, including any product placed on the market before 11 September 2026. Fines for non-compliance can reach €10 million or 2% of global annual turnover.

The second deadline is 11 December 2027. That is when the full CRA requirements kick in: CE marking, conformity assessment, complete coordinated vulnerability disclosure (CVD) programmes, SBOM management, security testing documentation, CSAF advisories, and the rest. That is the complex, expensive, time-consuming work.

Most companies we spoke to were treating these as one problem. They would hear “CRA compliance” and immediately jump to the 2027 requirements, conclude it was a multi-year programme they couldn’t start yet, and put it aside. Meanwhile, September 2026 was arriving and nobody had done anything about Article 14.

That is the gap CVD Portal was built to close.

What we actually built

CVD Portal is a hosted vulnerability disclosure management platform. Manufacturers register, configure their portal in a few clicks, and get a public submission URL they can link from their website and security.txt file. From that point, the platform handles the workflow.

Researchers submit vulnerabilities through a structured, tracked intake form and receive immediate confirmation with a tracking identifier. The portal monitors SLA deadlines, flags actively exploited vulnerabilities, and triggers the Article 14 notification timeline the moment a submission is escalated. The 24-hour, 72-hour, and 14-day ENISA reporting deadlines are tracked automatically, with reminders and status indicators at every stage. Every action, from receipt through acknowledgment, escalation, notification, and resolution, is logged to a tamper-evident audit trail that serves as compliance evidence. Secure, PGP-encrypted communication between the manufacturer and the researcher is built in.

Setting up a compliant, operational vulnerability disclosure programme takes less than five minutes. That is not a marketing claim; it is the product decision we made deliberately, because the companies that most need this are not the ones with a dedicated security engineering team. They are mid-sized industrial manufacturers, IoT device makers, and software vendors who have never run a CVD programme before and need something that works out of the box.

Why we made the September 2026 features permanently free

When we mapped Article 14’s requirements against what a manufacturer actually needs to be operationally compliant by September 2026, the list was finite and achievable: a public submission mechanism with tracking, an acknowledgment capability, an Article 14 notification workflow, SLA tracking, and an audit trail.

We could have charged for this. We chose not to.

The reasoning was straightforward. Hundreds of thousands of manufacturers across the EU face this deadline. Most of them are small and medium-sized businesses without compliance budgets, legal teams, or security specialists. If we charged for the minimum viable compliance tool, we would price out the companies that need it most, and the CRA’s September obligation would become a fine factory for SMEs who genuinely didn’t know what they needed to do.

So the Free tier of CVD Portal covers everything required for September 2026, permanently. No trial periods. No feature limits on the core Article 14 functionality. No credit card required to get started.

What we charge for, on our Pro and Enterprise tiers, are the capabilities that matter for the December 2027 deadline: SBOM management, CSAF advisory generation, security test plan documentation, full CVD programme tooling, multi-product management, and the compliance analytics that larger organisations need. That work is harder, takes longer to implement, and is where our commercial model sits.

The thinking behind the split

We were deliberate about separating these two deadlines in the product model because they represent genuinely different problems.

September 2026 is an operational problem. You need a working process and a documented audit trail. You need it now, and it shouldn’t require a six-month implementation project.

December 2027 is a programme-building problem. You need to build internal capability, integrate with your product development lifecycle, manage your component supply chain, and generate the compliance artefacts that a conformity assessment body will scrutinise. That is meaningful work, and it should start well before the deadline, ideally a year ahead.

By making the September tier free and getting companies onto the platform now, we give them something they actually need today, and we give them time to understand what the 2027 requirements will demand before those requirements arrive. That benefits them. It also benefits us: a manufacturer who has run their CVD programme on CVD Portal for eighteen months is a natural candidate to upgrade when they need SBOM management and CSAF advisories. We are comfortable with that alignment.

Where we are now

CVD Portal is live. The Free tier is available at cvdportal.com. Setup takes less than five minutes.

We are a small team with backgrounds in enterprise cybersecurity risk management and legal duty-of-care, and we have been building this product with a focus on regulatory accuracy from day one. We have read the CRA text carefully and tracked the implementing regulations, the ENISA guidance, and the harmonised standards work in progress. When the regulation says something specific, our product reflects what the regulation actually says, not a simplified approximation of it.

If you are a manufacturer with products on the EU market and you have not yet addressed your September 2026 obligations, the honest message is: the deadline is closer than it feels, and getting set up today costs you nothing.

CVD Portal is developed and operated by Porta Regulus BV. Questions? Reach us at hello@cvdportal.com.

Most discussion of NIS2 focuses on incident reporting and risk-management measures. The coordinated vulnerability disclosure side gets less attention, even though it shapes how every regulated organisation is expected to handle the moment a researcher arrives with a flaw. Here is what NIS2 actually asks for, in plain terms.

NIS2 Splits CVD Across Two Layers

NIS2 divides coordinated vulnerability disclosure between a national layer and an organisational layer.

At the national layer, every Member State must adopt policies that promote and facilitate coordinated vulnerability disclosure, and must designate at least one CSIRT to act as coordinator. That CSIRT receives vulnerability reports, follows up on them, protects the anonymity of the reporter where requested, and coordinates between parties when a flaw affects more than one vendor. Member States must also allow a person to report a vulnerability anonymously, and give researchers a degree of legal protection when they follow the rules.

At the organisational layer, essential and important entities must treat vulnerability handling and disclosure as part of their risk-management measures. This is the part that lands on companies rather than governments. NIS2 does not set out a full template, but the NIS Cooperation Group guidance fills that gap with a clear set of expectations.

What a CVD Policy Is Expected to Contain

The guidance reads almost as a checklist. An organisation adopting its own CVD policy is expected to cover the following.

• Scope. State plainly which systems and services are in scope, and list anything provided by third parties that is excluded. Reporters should not have to guess.
• A point of contact. A dedicated channel for reports, such as a security address or an online form, with internal routing so reports arriving through other channels reach the right team. A security.txt file on the website helps researchers find it.
• Proportionality. The reporter should not disrupt service or go further than needed to demonstrate the flaw, and should not retain data, including personal data, longer than necessary.
• Good faith. The organisation commits not to pursue legal action against a reporter who follows the policy. The reporter commits to acting without intent to harm.
• Confidentiality. Reporters do not share what they find with third parties, beyond the designated CSIRT or competent authority, and do not go public without agreement.
• Personal data handling. Because a reporter may come across personal data, the policy should set written obligations on how that data is handled, limited to what is needed to prove the flaw exists and protected by encryption. For data protection professionals, this is the part worth close reading. A CVD policy can function as a form of agreement binding the researcher to the organisation, which has direct GDPR consequences for who counts as controller and on what lawful basis the data is processed.
• Reward or recognition. Optional. This ranges from a public acknowledgement or hall of fame through to a bug bounty. Recognition costs almost nothing and still raises the quality of reports.

The Operational Side

Beyond the policy text, the guidance sets expectations for how the process runs day to day.

Communication should be secure, using encryption or a protected portal, so details of an unpatched flaw do not leak. Each stage should have a deadline, for acknowledging receipt, for progress updates, for developing a fix and for any publication, while staying flexible enough for genuinely complex cases. Disclosure to the public should be coordinated with the affected parties and the designated CSIRT, so there is time to fix the flaw and warn affected users before details become public. Where a product depends on upstream components, the vendor is expected to track those dependencies and pass vulnerability information both up to suppliers and down to customers.

None of this is exotic. It is the difference between a process that holds up under scrutiny and a security address that someone checks when they remember to.

Why This Matters Now

NIS2 sets the EU-wide expectation that organisations run a proper coordinated vulnerability disclosure process. It raised the floor. What it does not do is impose specific, deadline-bound disclosure duties on every manufacturer of a connected product.

That is where the Cyber Resilience Act comes in. The CRA takes the same coordinated disclosure thinking and makes it binding on manufacturers placing products with digital elements on the EU market, with concrete obligations and hard deadlines. The vulnerability handling expectations NIS2 describes in principle, the CRA turns into a legal requirement with a date attached.

If you have read this far because NIS2 applies to you, the CRA is the next document on your desk. The good news is that an organisation that builds a credible CVD process for NIS2 has already done most of the groundwork for what the CRA will require.

Source: NIS Cooperation Group, Guidelines on Implementing National Coordinated Vulnerability Disclosure Policies, 2023.