Vulnerability Handling Policy: Incutec BV

ENISA reporting under CRA Article 14 applies from 11 September 2026. Full CRA vulnerability-handling obligations apply from 11 December 2027.

CRA (EU) 2024/2847 applies from 11 December 2027, with Article 14 vulnerability reporting from 11 September 2026.

Applies to all Incutec products with digital elements (firmware).

Policy

Incutec BV handles security vulnerabilities in its products responsibly: monitoring upstream projects, coordinating disclosure with researchers in good faith, and reporting to ENISA when required.

Belgian framework

Researchers acting in good faith under this policy benefit from the protection of the Belgian coordinated vulnerability disclosure framework (Act of 26 April 2024 and relevant CCB provisions). We recommend simultaneously notifying the Centre for Cybersecurity Belgium (CCB) at vulnerabilityreport@ccb.belgium.be — see https://ccb.belgium.be/en. Simultaneous notification to the CCB may confer criminal-law immunity under Art. 550bis of the Belgian Penal Code for research that might otherwise qualify as unauthorised access.

The CCB also acts as a CVE Numbering Authority for Belgium.

Coordinated Vulnerability Disclosure (Safe harbour)

Incutec welcomes vulnerability reports from security researchers. If you make a good-faith effort to comply with this policy during security research, we will:

• Not pursue or support any legal action against you
• Work with you to understand and resolve the issue quickly
• Credit you in the security advisory (unless you prefer to remain anonymous)

In scope

• Incutec-designed hardware (flight controllers, ESCs, ELRS receivers, and any future products)
• Firmware shipped or distributed by Incutec, including board-target definitions upstreamed to Betaflight, AM32, or ExpressLRS
• incutec.eu, opendrone.be, and subdomains directly operated by Incutec

Out of scope

• Denial of service attacks and volumetric testing
• Physical attacks, social engineering, or phishing of staff
• Third-party services not operated by Incutec (Shopify, Stripe, hosting providers)
• Reports generated solely by automated scanners without proof of exploitability

Contact

Security issues: security@opendrone.be Machine-readable record: /.well-known/security.txt (RFC 9116)

A PGP key will be published here and in security.txt once key infrastructure is in place. Until then, start with a non-sensitive initial contact and we will establish an encrypted channel before exchanging technical details.

ENISA Registration

Incutec will register with ENISA's Single Reporting Platform (SRP) before 11 September 2026. The ENISA portal URL will be published here once the platform is operational.

Firmware Version Tracking

Each shipped product is associated with a firmware version. When a security patch is released, the version is updated and the CVE identifier (if any) is recorded in the product's release notes and on the product page.

Upstream CVE Monitoring

Parts of Incutec's firmware stack are based on upstream open source projects: Betaflight (GPL-3.0), AM32 (GPL-3.0), and ExpressLRS (GPL-3.0). We also maintain in-house firmware for some products. Monitoring:

• GitHub Security Advisories for upstream repositories
• OSV.dev for CVEs affecting those projects
• Release notifications on upstream repositories

Manual review is performed when upstream projects publish security releases. In-house firmware is monitored through the internal issue tracker and the security@opendrone.be inbox.

Reporting Process

External reports (always active)

Responsible disclosure is accepted at all times, independent of the CRA transition dates.

1. Researcher reports to security@opendrone.be
2. Acknowledge receipt within 48 hours
3. Assess and triage within 5 business days
4. Coordinate patch timeline with the reporter; credit unless they prefer anonymity
5. Default embargo: 90 days from initial report or until a patch is publicly available, whichever comes first. Embargoes may be extended by mutual agreement, for example where upstream projects need additional time to coordinate a joint release

ENISA reporting (from 11 September 2026)

CRA Article 14 requires notification of actively exploited vulnerabilities AND severe incidents having an impact on the security of the product.

"Awareness" for the purposes of CRA Article 14 means the moment Incutec obtains sufficient evidence that a vulnerability is being actively exploited or that a severe incident has occurred.

Internal discovery

1. Document in a private issue (not public GitHub)
2. If actively exploited or if a severe incident has occurred: report to ENISA within 24 hours per the table above
3. Develop and release a patch
4. Publish a security advisory after the patch is available

Patch Distribution and User Notification

1. Publish patched firmware on GitHub releases with a GitHub Security Advisory
2. Publish a product-page update and a note on the security advisories page
3. Notify users via email where purchase records exist
4. Update the SBOM for the affected product (CRA Annex I Part II) and make the new SBOM available on the product page

Product Support Lifetime

CRA requires manufacturers to provide security updates for the expected product lifetime. Incutec commits to security updates for a minimum of 5 years from the last ship date of a given product, unless a longer period is stated on the product page. End-of-support notices will be published on the product page and on the security advisories page at least 6 months before support ends.

Open Source Considerations

For vulnerabilities located in upstream code (Betaflight, AM32, ExpressLRS), Incutec coordinates disclosure with those projects first and respects their embargo periods before any public disclosure. Patches merged upstream are mirrored into Incutec's release channels.

Severity Triage

Severity is assessed using CVSS v3.1. Indicative patch SLAs:

Timelines may be extended where coordination with upstream projects is required.

Policy effective: 20 April 2026 (date the BV becomes operational) Approved by: Managing Director, Incutec BV

Report security issues to security@opendrone.be. See /.well-known/security.txt for the machine-readable contact record.