OnLogic designs and manufactures industrial and embedded computing products. We are committed to protecting our customers against cybersecurity risks affecting our products, and to providing timely information and mitigation options when vulnerabilities are identified.

This policy describes how anyone — security researchers, customers, partners, suppliers, or members of the public — can report a suspected security vulnerability in an OnLogic product, and what they can expect from us in return. It applies worldwide.

We do not pursue legal action against people who report vulnerabilities to us in good faith and in line with this policy.

The purpose of a vulnerability disclosure policy is to establish a clear and trusted method for security researchers to report vulnerabilities related to OnLogic products. It outlines the following:

• Provide a single, monitored reporting channel so vulnerabilities reach the right team quickly rather than being disclosed publicly or exploited.

• Set clear mutual expectations on acknowledgement, assessment, remediation and disclosure timeframes.

• Enable coordinated disclosure, so that customers receive a fix or a mitigation before technical details become public.

• Improve product security by feeding every validated report back into OnLogic's secure development lifecycle.

In scope

• OnLogic-branded hardware products, including industrial PCs, edge computers and gateways.

• OnLogic-supplied firmware, BIOS/UEFI images, drivers, board support packages and bundled software.

• OnLogic-supplied remote data-processing components (BMC), where OnLogic provides them as part of the product.

Out of scope

• OnLogic corporate IT, websites, e-commerce or cloud accounts — report to soc@onlogic.com.

• Third-party operating systems and open-source components where OnLogic is not the upstream maintainer. Report these to the responsible upstream project or vendor. If the issue is in how OnLogic integrates, configures or ships that component, it is in scope for PSIRT — please report it to us as well.

• Physical attacks require destructive disassembly of a device already in the attacker's sole possession, unless a documented security control is thereby bypassed.

• Reports consisting only of automated scanner output with no demonstrated impact.

• Social engineering of OnLogic staff, customers or suppliers.

• Denial of service achieved solely by volumetric flooding of a public service.

Prohibited activity 

When testing, do not: access, modify, exfiltrate or destroy data belonging to OnLogic or a third party; degrade production systems or customer environments; test on hardware you do not own or lack written permission to test; or use a finding for any purpose other than reporting it to us. 

Send reports to psirt@onlogic.com. This mailbox is monitored by the OnLogic PSIRT and is intended only for reporting suspected product or service vulnerabilities. For product technical support, use support@onlogic.com.

Please include as much of the following as you can:

• Product name, model/SKU, and firmware, BIOS or software version affected.

• A technical description of the vulnerability and the security impact.

• Reproduction steps, proof-of-concept code or configuration, and any relevant logs.

• Your estimated severity — a CVSS v3.1 or v4.0 score and vector string.

• Any suggested remediation or mitigation.

• Whether you intend to publish, and on what timeline.

• Your own vulnerability disclosure policy, if you have one.

• How you would like to be credited, or that you prefer to remain anonymous.

Reports must be submitted in English to ensure the fastest handling. Anonymous reports are accepted; note that we cannot provide status updates or credit if we have no way to contact you.

What you can expect

Target remediation windows, measured from confirmation of the vulnerability:

Actual timing depends on the complexity of the fix, the number of affected product lines, the availability of upstream or supplier patches, and validation testing needed to avoid regressions in industrial deployments. Where a full fix will take longer than the target window, OnLogic will publish an interim mitigation or workaround.

Safe harbour for good-faith research

If you make a good-faith effort to comply with this policy during your security research, OnLogic will:

• Consider your research authorised, and will not initiate or support legal action against you in connection with it;

• Not report you to law enforcement in connection with the research;

• Work with you to understand and resolve the issue quickly;

• Publicly acknowledge your contribution in the resulting security advisory, if you wish.

This protection applies to research conducted on hardware you own or are authorised to test, where you act in good faith, avoid privacy violations and service disruption, and give OnLogic a reasonable opportunity to remediate before public disclosure.

Safe harbour does not extend to activity that violates applicable law independently of this policy, and OnLogic cannot waive the rights of third parties. If a third party takes action against you for research conducted in compliance with this policy, we will make clear that your activity was authorised.

OnLogic does not currently operate a paid bug bounty programme. We recognise contributors through advisory credit.

Coordinated disclosure

OnLogic follows coordinated disclosure. Our default coordination window is 90 days from the date we acknowledge a valid report, after which the reporter is free to publish.

• We will normally publish a security advisory at the same time as, or before, the fix is generally available.

• If more time is needed — for example where the fix requires a supplier firmware change or affects many product lines — we will explain why and propose a revised date. We ask that you work with us on the extension; we will not extend indefinitely.

• If a vulnerability is being actively exploited, we may publish earlier, with mitigations, and will tell you before we do.

• Please do not disclose details publicly before the coordinated date without first talking to us.

Where a vulnerability affects components supplied to OnLogic by a third party, or where OnLogic receives information under embargo or a non-disclosure agreement, we will work with the supplier to have a fix released. In those cases we may be unable to share technical details until the supplier's own disclosure timeline permits.

Severity assessment

OnLogic assesses product vulnerabilities using the Common Vulnerability Scoring System (CVSS), versions 3.1 and 4.0. Each advisory states the numeric base score, the vector string, and the qualitative rating (Critical, High, Medium, Low).

CVSS base scores describe the technical characteristics of a vulnerability, not the risk to a particular deployment. OnLogic supplements the base score with environmental and exploitability considerations relevant to industrial and edge deployments — network exposure, availability impact on essential functions, and whether exploitation has been observed in the wild — when setting remediation priority. Where a CVE identifier is assigned, OnLogic references it in the advisory.

How OnLogic handles a report

The OnLogic PSIRT is a global team responsible for receiving, investigating, remediating and publicly reporting security vulnerabilities in OnLogic products. Handling follows OnLogic's IEC 62443-4-1 certified practices:

1. Intake — the report is logged and assigned a tracking reference. The reporter receives acknowledgement.

2. Triage and assessment — PSIRT reproduces the issue, scores it, and determines the affected product lines, firmware versions and lifecycle status.

3. Regulatory reporting decision — PSIRT determines whether statutory reporting obligations are triggered and, if so, notifies Legal and Infrastructure & Security immediately.

4. Remediation — a fix or mitigation is developed, qualified and regression-tested to confirm it does not affect product operation.

5. Disclosure — a security advisory is published describing the vulnerability, affected products, impact and remediation.

6. Closure and learning — the report is closed, the affected products' Software Bill of Materials is updated, and findings are fed back into the secure development lifecycle.

Regulatory reporting

Separately from the coordination process above, OnLogic reports actively exploited vulnerabilities and severe incidents affecting the security of its products to the European Union Agency for Cybersecurity (ENISA) and the relevant national Computer Security Incident Response Team (CSIRT), as required by Article 14 of Regulation (EU) 2024/2847, on the following timeline:

Where required, OnLogic will also inform affected users of the vulnerability or incident and of any corrective measures or mitigations they can deploy.

Statutory reporting is a legal obligation and is not subject to the coordination window. It does not result in public disclosure of technical details ahead of an advisory.

Security updates, advisories and support period

• Security advisories are published at . Each advisory identifies the affected products and versions, describes the vulnerability and its impact, and states the remediation or mitigation available.

• Security updates are provided free of charge to all users of standard non customized products within the support period, and are distributed through authenticated, integrity-protected channels. Updates are cryptographically signed and verified by the device before installation.

• Support period. OnLogic provides security updates for a minimum of five (5) years from the date a product is placed on the market, unless a longer period is stated in the product documentation. The applicable support period for each product is stated in its product documentation.

• End of support. OnLogic gives at least 12 months' notice before security update support for a product ends.

• Notification. Customers can subscribe to security advisory notifications at www.onlogic.com/security/advisories. Advisory messages accompany security updates where the update mechanism supports it.

Software Bill of Materials

OnLogic maintains a machine-readable Software Bill of Materials (SBOM) in a commonly used standard format (CycloneDX) for products with digital elements placed on the EU market, generated in the build pipeline and regenerated at each release.

SBOMs are retained with the product technical documentation and are made available to market surveillance authorities on request. OnLogic is not obliged to publish SBOMs; customer requests for a product SBOM are handled case by case through your OnLogic account contact, subject to confidentiality terms.

Handling of personal data

Personal data contained in a vulnerability report — such as your name and contact details — is used only to communicate with you about the report, to credit you in an advisory if you wish, and to meet regulatory reporting obligations. It is retained for as long as necessary for those purposes and for the record-retention periods required by applicable regulation. Questions about how OnLogic handles your data can be directed to the contact in OnLogic's privacy notice.

Contact

Disclaimer

This policy describes OnLogic's current vulnerability disclosure and handling practices and may be amended. It does not create a contractual obligation, warranty or service level commitment, and does not modify the terms of any agreement between OnLogic and its customers. Response is not guaranteed for any specific issue or class of issues, and use of the information in this document or in linked materials is at your own risk.