Cyber Vulnerability Disclosure Policy

If you have found a security weakness in an Incosa product, we want to hear from you. This page explains how to report it, what we will do with it, and what you can expect from us in return.

Version 1.1

1. Our commitment

Security researchers, customers, partners and members of the public who find a security weakness in an Incosa product are doing us — and the people who work around our equipment — a service. We want to hear from you, we will take your report seriously, and we will work with you to get it fixed.

We follow the principle of coordinated disclosure: we ask for a reasonable period to develop a fix or mitigation before details become public, and in exchange we commit to working the problem promptly, keeping you informed, and crediting your work publicly.

2. What this policy covers

This policy applies to security vulnerabilities in any product sold under the Incosa brand, and to the websites we operate:

It applies worldwide. Wherever you are, and wherever the affected product was supplied, we want the report.

2.1 Not covered by this policy

• Products past the end of their support period (see section 3). We will still read your report, tell you the product is out of support, and check whether the same weakness affects any product still in support. We do not commit to issuing a fix.
• Third-party products not integrated into ours. Please report those to the vendor concerned. If a third-party component is inside an Incosa product, that is in scope — see section 8.
• Non-security matters. Functional bugs, feature requests and product support questions belong in our normal support channels.

2.2 Findings we normally close as informational

The following, on their own and with no demonstrated security consequence, will usually be closed as informational. Send them anyway if you think we are wrong — we will explain our reasoning, and we will reconsider if you can show real impact.

• Version banners. A device or tool reporting its own firmware or software version — in an HTTP header, a service banner, a status page or a configuration dialogue — is not a vulnerability. Our equipment is designed to tell a commissioning engineer what it is running. It becomes relevant only when combined with something exploitable.
• Missing security headers or cookie flags with no exploitable consequence.
• Raw output of an automated scanner, with no manual validation and no demonstrated impact.
• Denial of service achieved purely through volume of traffic.
• Social engineering of Incosa staff, customers or partners.
• Theoretical attacks requiring an implausible precondition — for example, an attack requiring an attacker to have already achieved full administrative control of the engineering PC.

2.3 A note on attacks requiring physical access

Most Incosa control equipment is installed on overhead cranes and comparable industrial machinery: mounted at height, inside enclosures, in restricted-access industrial premises, and very often not attached to any network. Reaching one physically is not trivial.

We therefore weigh physical-access findings by what an attacker realistically has to achieve first. We do not dismiss them. In particular we do want to hear about:

• anything that lets an attacker move from a device to the wider installation, or to other machines;
• anything affecting the integrity or authenticity of firmware or configuration — a device accepting unsigned, tampered or downgraded firmware matters a great deal to us, whatever access it takes;
• anything recoverable from a device that would compromise other installations — shared keys, embedded credentials, reusable secrets;
• anything reachable through the engineering and commissioning path — programming tools, configuration files, service laptops, USB media — where it goes beyond normal usage and expected behaviour. An engineer with authorised access to the programming tools is meant to have full control of the device; that is the design, not a flaw. What interests us is where that path can be abused: an unauthorised person reaching it, a configuration file doing something it should not, a tool accepting input it should reject, or an engineering action reaching further than it was ever intended to.

What we are less interested in is a finding that requires an attacker to disassemble a device they already own, yields access only to that device, and does not affect anyone else.

3. Support period

The support period for Incosa products is five years from the date the product is placed on the market.

For cloud services, five years applies as an interim position and will be reviewed when those services enter general availability.

During the support period we handle vulnerabilities in the product under this policy. The support period end date for a specific product is stated at the time of purchase and in the product documentation.

3.1 How fixes actually reach you — please read this

Incosa control equipment is safety-related and, in most installations, air-gapped. There is usually no remote update path, and pushing an automatic update to a device that controls a crane in service would itself be a safety event. This shapes how we deliver fixes, and we would rather be straightforward about it than imply a capability we do not have.

What we do

1. We publish. Every fixed vulnerability is published in the security advisories section of our documentation library and named in the release notes for the firmware or software version that fixes it, with credit to the reporter.
2. We make the update available free of charge, and you can request it from us at any time during the support period. Security updates are never charged for.
3. For installations Incosa delivered or programmed, we review the affected projects ourselves, and where the vulnerability is relevant and material to that installation we contact the customer directly rather than waiting to be asked.
4. Where we cannot fix something, we publish the mitigation — configuration changes, network segregation, operational measures — so you can protect the installation while a fix is developed, or in place of one.

4. How to report

A human reads this mailbox — it is monitored by our R&D and management team. There is no required format. Plain email is fine, and we will never turn a report away because it arrived in an unexpected shape.

If you would like something to work from, we publish an optional report template covering everything we find useful. Use it or ignore it entirely. A partial report is far better than none, and a one-line email that turns out to matter is worth more to us than a perfectly formatted one that never gets sent.

Would you rather talk it through? Say so in your first message and we will arrange a call. We will not require you to use a web form or any automated tool.

4.1 What helps us most

• Which product — line, model, hardware revision, firmware or software version
• What the problem is, in plain terms
• How to reproduce it — steps, configuration, tooling
• What an attacker could achieve
• What access an attacker would need — network position, physical access, credentials, user interaction, engineering-tool access
• Proof-of-concept code, logs, screenshots, packet captures
• How you would like to be credited, or that you would prefer to stay anonymous
• Whether you intend to publish, and when

4.2 Confidentiality

Please do not post vulnerability details in public issue trackers, forums, social media or our general support channels before contacting us.

We do not currently publish a PGP key. If you need to send something you are not comfortable putting in plain email, tell us and we will agree a secure channel with you.

5. What you can expect from us

Commitments we make to you, in business days, Belgian working calendar.

If we are going to miss one of these, we will tell you before the deadline rather than after, and explain why.

5.1 What we will not do

• We will not ask you to sign a non-disclosure agreement as a condition of accepting or investigating your report.
• We will not use the process to delay you indefinitely. If we cannot fix something, we will say so and explain why.
• We do not operate a paid bug bounty programme. We offer public credit in our advisories and release notes, and our genuine thanks. If that changes, this page will say so.

6. Safe harbour

Where you act in good faith and within the rules in section 9, Incosa Solutions:

• will not initiate or support civil or criminal proceedings against you in connection with your research or your report;
• will not report you to law enforcement in connection with that research;
• will treat your activity as authorised for the purposes of any applicable computer misuse, unauthorised access or anti-circumvention law, and will say so if a third party questions it;
• will not treat your report as a breach of any contract or terms of service between us, and waives any claim arising from that.

If a third party brings legal action against you for research conducted in accordance with this policy, we will make clear — publicly if necessary — that your activity was authorised by us.

6.1 The limits of this promise, stated plainly

• It covers your own testing on equipment you own or are authorised to test. It does not authorise you to test a customer’s live installation. We cannot waive rights that belong to our customers — only our own.
• It does not cover accessing, downloading, modifying or retaining other people’s data beyond the minimum needed to demonstrate the problem.
• It does not cover disrupting production systems, safety functions or machinery in operation.
• It does not apply if you use the vulnerability for extortion, for commercial advantage, or to cause harm.
• It is a statement of Incosa’s position. It cannot bind a public prosecutor or a court in any jurisdiction, and it does not change the law in any country. If you are uncertain about the legality of what you intend to do, take your own legal advice first.

7. Coordinated disclosure and timing

7.1 Our default

We aim to have a fix or mitigation available, and to publish, within 90 days of acknowledging your report — or with the next firmware or software release for the affected product, whichever comes first.

• We agree the publication date with you. If you want a different timeline, tell us early and we will try to accommodate it.
• If we need longer than 90 days, we will explain why, give you a revised date, and keep you updated. Embedded and safety-related equipment sometimes needs it: a fix has to be validated against machinery behaviour before it can responsibly be released.
• If you decide to publish before we are ready, we ask that you tell us first. We will not threaten you for it.

7.2 Publishing before a fix exists

Occasionally the balance tips the other way — a vulnerability is being exploited, or details are already circulating. We may then publish mitigations and warnings before a full fix exists, because operators need to protect their installations. We will tell you if we are going to do this.

7.3 Where we publish

Fixed vulnerabilities are published in two places:

1. A dedicated security advisories section of our documentation library, with a stable reference per advisory so it can be cited by you, by customers and by national CERTs.
2. The release notes for the firmware or software version containing the fix, naming the vulnerability and crediting the reporter.

7.4 When we delay publication

We may hold back publication of a fixed vulnerability where making details public would put operators at greater risk than keeping them quiet — typically where a fix exists but users have not yet had a realistic opportunity to install it. Given that most of our equipment is air-gapped and updated by hand, that window is sometimes longer than it would be for connected consumer products.

This is a deferral, not a cancellation. We publish once users have had that opportunity, and we record the reason each time.

8. Vulnerabilities in third-party components

Our products contain software and hardware from other suppliers, including open-source components. If your report turns out to concern one of those:

• We will fix or mitigate it in our product regardless of who wrote the code.
• We will report it to the supplier or the open-source project that maintains it.
• Where we develop the fix ourselves, we will offer that fix back to the upstream maintainer.
• We will coordinate publication timing with the upstream project where they need it.

This can lengthen the timeline, because upstream projects have their own disclosure processes. We will keep you informed.

9. Rules of engagement

We ask you to:

• Test only on equipment you own, or that you have written permission to test. Do not test a customer’s installation without that customer’s authorisation.
• Never touch machinery, safety functions or production systems in operation. See the note below.
• Stop as soon as you have demonstrated the problem. Do not go further into a system than you need to in order to show impact.
• Do not access, copy, alter or delete other people’s data. If you encounter personal or confidential information, stop, do not retain it, and tell us what you saw so we can assess the exposure.
• Do not degrade service. No volumetric denial of service, no spam, no brute-forcing that would lock out real users.
• Do not use social engineering, phishing or physical intrusion against Incosa staff, our customers, our suppliers or our premises.
• Keep the details confidential until we have agreed publication timing, or until the period in section 7 has run.
• Comply with the law in your jurisdiction and in ours.

9.1 Additional rules for our websites

Our websites are in scope (section 2), and a few things apply specifically to them:

• No automated scanning that degrades the site. Rate-limit your tooling. A scan that takes a site down is a denial of service, whatever the intent behind it.
• Do not test third-party services. Our hosting, CDN, DNS, analytics, email delivery and payment providers are not ours to authorise testing against, and our safe harbour cannot cover you there. Findings about their configuration belong with them.
• Do not test subdomains or services we do not control. If you are unsure who operates something, ask us before testing it.
• Do not access other people’s accounts or data. If a flaw would let you, stop at the point of demonstrating it and tell us.
• No spam, no mass account creation, no mass form submission.

Findings we normally close as informational on the websites: SPF, DKIM and DMARC configuration; missing security headers on static pages; absent rate limiting on public forms; TLS configuration matching current provider defaults; version disclosure of web software; content hosted by third parties. As always — if you can show real impact, send it and we will look.

---

Reports made in good faith under these rules are welcome even if it turns out there is no vulnerability. We would rather investigate ten false alarms than miss one real problem.

10. Credit

Unless you tell us otherwise, we credit you by name when the vulnerability is published — in the advisory, in the release notes for the version containing the fix, and in our acknowledgments at the end of this page.

Tell us how you would like to be named, or that you would prefer to remain anonymous. Either is completely fine. If you are reporting on behalf of an organisation, tell us which name to use.

11. A note on regulatory reporting

Incosa Solutions is subject to the EU Cyber Resilience Act (Regulation (EU) 2024/2847). In certain cases — principally where there is reliable evidence that a vulnerability is being actively exploited — we are legally required to notify European cybersecurity authorities within fixed deadlines, in parallel with our work with you.

What that means for you

• We may have to notify authorities before we have finished investigating, and before agreeing any timing with you. We have no discretion about this.
• Notifying authorities is not publishing. Those notifications go to designated national cybersecurity teams and to ENISA, not to the public. The receiving authority can withhold onward distribution where a vulnerability is under coordinated disclosure.
• It does not shorten your credit or change our commitments to you under this policy.
• It does not put you at risk. We do not name reporters in regulatory notifications unless you ask us to.

Vulnerabilities found through good-faith research, testing or investigation — with no malicious intent — are not, by that fact alone, subject to mandatory notification.

For products supplied outside the European Union we apply the same security standards and the same handling process. The specific EU notification deadlines are an EU legal requirement and do not apply to those markets — but where a product sold in the EU is affected, the EU obligations apply regardless of where the problem was found.

12. If you are unhappy with how we handled your report

Write to cybersecurity@incosasolutions.com and ask for the matter to be escalated to Incosa management. If you remain dissatisfied, you may raise it with the national cybersecurity authority in your country. In Belgium that is the Centre for Cybersecurity Belgium (CCB / CERT.be).

13. Changes to this policy

Previous versions are available on request, so you can see what applied at the time you reported.

14. Acknowledgments

Our thanks to the security researchers below, who reported vulnerabilities in Incosa products responsibly and gave us the chance to fix them before anyone was harmed. Every one of them chose to tell us first. We are grateful for that, and we think they deserve to be named for it.

Each entry links to the advisory describing the issue, and to the release notes for the version that fixed it.

14.1 How to get listed

Report a vulnerability to us and follow this policy. That is the whole requirement — there is no minimum severity and no competition.

• We add you when the advisory is published, not when you report. That is usually within 90 days of us acknowledging your report, or with the next release for the affected product, whichever comes first.
• You choose how you are named. Your own name, a handle, your organisation, or anonymously — just tell us in your first message. You can change your mind before publication.
• Anonymous entries still appear, credited as “Anonymous researcher”. The finding happened, and the record should show it.
• You are credited even where no code change was needed, if the report led to a published advisory — for example where we published a mitigation or configuration guidance instead.
• We do not run a paid bug bounty. What we offer is public credit here, in the advisory itself, and in the release notes for the version that fixed the issue — plus our genuine thanks.

If you reported something and are not listed, or your name is recorded incorrectly, or you would like it removed, email cybersecurity@incosasolutions.com and we will correct it. You can ask to be removed at any time, including after publication.

---

Incosa Solutions
Security contact: cybersecurity@incosasolutions.com
Management escalation: arno.claes@incosasolutions.com
Machine-readable contact information: /.well-known/security.txt