Responsible Disclosure Policy
Digi International Inc. endeavors to ensure our customers have confidence in the security of our products and services. If you have discovered a security vulnerability on Digi.com or any Digi branded Product or Service, we request that you disclose it to us in accordance with this Responsible Disclosure Standard.
To deliver a safe and secure mechanism for our customer base and researchers, we partner with Bugcrowd Inc. (“Bugcrowd”) and leverage their Vulnerability Disclosure Program platform. Upon validation of a submission, Digi will fix vulnerabilities according to our risk management standards for continued commitment to confidentiality, integrity, and availability of our infrastructure and products.
To report a suspected vulnerability, please submit detailed information using the form at the bottom of this page. Please review the vulnerability submission report data section for suggestions for what to provide for case details.
Security Decorum
Below outlines our expected behavior, etiquette, and principles governing interactions within the context of security related activities for participating in our vulnerability disclosure program.
- Always comply with data protection rules and do not violate the privacy of our users, staff, contractors, services, or systems.
- You must not, for example, share, redistribute or fail to rightly secure data retrieved from the systems or services.
- You must not access, download, or modify data that does not belong to you.
- Do not Disclose any identified or alleged vulnerability addressed in your submission to the public or a third party without express written consent from Digi.
- Securely delete all data retrieved during your research as soon as it is no longer required or within one month of the vulnerability being resolved, whichever occurs first (or as otherwise required by data protection law).
Submission Communication Lifecycle
Digi’s Security Team is committed to coordinating with the researcher as transparently and quickly as possible. The submission lifecycle includes the following:
- Researcher or customer submits the form following our Vulnerability Disclosure Standard and Program.
- All communication with Digi about the vulnerability submitted will be conducted through the email provided in Bugcrowd Vulnerability Disclosure platform submission. (Note: To communicate with Digi and Bugcrowd’s Security team, you must claim the submission through an email validation sent to your email from Bugcrowd.)
- Digi’s security team responsible for vulnerability coordination will acknowledge receipt of potential vulnerabilities within four days of a submission. For zero days we will acknowledge receipt of potential zero day within 24 hours of the submission.
- Digi’s security team is specified as Digi_Sec_(name of Digi staff member) in the communication chain and will continuously update the submitter throughout the lifecycle of the vulnerability.
- Bugcrowd and Digi’s security team will assess the vulnerability based on our risk classification system.
- Upon determining the validity of the vulnerability, it will be triaged according to the product team’s lifecycle management process. Results may require action via Digi’s patch policies located here: https://www.digi.com/resources/security/security-policies
- For all other products support statements including information on End-of-Life products (“EOL”) go to: https://www.digi.com/support/support-policy
Regulatory Reporting — EU Cyber Resilience Act, Article 14
In addition to the submission lifecycle described above, Digi International is subject to the reporting obligations set out in Article 14 of Regulation (EU) 2024/2847 (the “Cyber Resilience Act” or “CRA”) in respect of Digi products with digital elements made available on the European Union market. These obligations apply from 11 September 2026. This section describes Digi’s reporting obligations only; it does not alter the submission, triage, or remediation processes set out elsewhere in this Standard.
Reportable Events
Article 14 requires Digi to notify the CSIRT designated as coordinator and ENISA, simultaneously, via the single reporting platform established under Article 16 of the CRA, upon becoming aware of either of the following:
- An actively exploited vulnerability contained in a Digi product with digital elements.
- A severe incident having an impact on the security of a Digi product with digital elements. Under Article 14(5), an incident is severe where it negatively affects, or is capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions; or where it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user of the product.
Reporting Timelines
All timelines run from the point at which Digi becomes aware of the qualifying event.
For an actively exploited vulnerability (Article 14(2)):
- Early warning notification — without undue delay and in any event within 24 hours of Digi becoming aware, indicating, where applicable, the Member States in whose territory Digi is aware the affected product has been made available.
- Vulnerability notification — without undue delay and in any event within 72 hours of Digi becoming aware, providing general information, as available, about the affected product, the general nature of the exploit and of the vulnerability, any corrective or mitigating measures taken, corrective or mitigating measures that users can take, and, where applicable, an indication of how sensitive Digi considers the notified information to be.
- Final report — no later than 14 days after a corrective or mitigating measure is available, including at least a description of the vulnerability and its severity and impact; where available, information concerning any malicious actor that has exploited or is exploiting the vulnerability; and details about the security update or other corrective measures made available to remedy the vulnerability.
For a severe incident (Article 14(4)):
- Early warning notification — without undue delay and in any event within 24 hours of Digi becoming aware, including at least whether the incident is suspected of being caused by unlawful or malicious acts, and indicating, where applicable, the Member States in whose territory Digi is aware the affected product has been made available.
- Incident notification — without undue delay and in any event within 72 hours of Digi becoming aware, providing general information, where available, about the nature of the incident, an initial assessment of the incident, any corrective or mitigating measures taken, corrective or mitigating measures that users can take, and, where applicable, an indication of how sensitive Digi considers the notified information to be.
- Final report — within one month after submission of the incident notification, including at least a detailed description of the incident and its severity and impact; the type of threat or root cause likely to have triggered the incident; and applied and ongoing mitigation measures.
Where the CSIRT designated as coordinator that initially receives a notification requests it, Digi will provide an intermediate report on relevant status updates, as provided for in Article 14(6).
Notification to Users
After becoming aware of an actively exploited vulnerability or a severe incident having an impact on the security of a product with digital elements, Digi will inform impacted users of that product, and where appropriate all users, of the vulnerability or incident and, where necessary, of any risk mitigation and corrective measures that users can deploy to mitigate its impact — where appropriate in a structured, machine-readable format that is easily automatically processable, as provided for in Article 14(8).
Effect on Submitters
- Information provided in a submission under this Standard may be used by Digi to prepare and support notifications required under Article 14.
- Digi’s Article 14 notifications are made in confidence to the designated CSIRT and ENISA and do not constitute public disclosure. The confidentiality expectations set out in the Security Decorum section continue to apply to submitters unless and until Digi provides express written consent to disclose.
- The Article 14 timelines run from the point at which Digi becomes aware of a qualifying event, independently of the acknowledgment commitments described in the Submission Communication Lifecycle section.
- If you have evidence that a vulnerability is being actively exploited, please state this clearly and prominently at the top of your submission so that Digi can assess the 24-hour early warning obligation without delay.
How to Flag a CRA Submission
If your submission concerns a Digi product with digital elements made available on the European Union market, and you believe it may relate to an actively exploited vulnerability or a severe incident as described above, please route it so that Digi’s security team can identify it immediately:
- Target: select “Cyber Resilience Act (CRA)” from the Target drop-down on the Bugcrowd embedded submission form.
- Summary Title: include the text “Cyber Resilience Act (CRA)” in the Summary Title of your submission, together with your usual short description of the issue.
Selecting the CRA Target and including “Cyber Resilience Act (CRA)” in the Summary Title does not change how the submission is triaged or rated under this Standard. It allows Digi to assess the Article 14 reporting timelines without delay.
Included Submission Types
- Business Logic vulnerabilities
- OWASP Top 10
- Information Disclosure
- Data Exposure
- Authorization/Authentication issues
- Anything outside of the above list that could or currently impacts the confidentiality, integrity, or availability of Digi systems, services, or Digi property can be submitted.
Vulnerability Submission Report Data
The following information would better assist Digi’s and Bugcrowd’s Security team to validate and triage the vulnerability.
- Product or service name, URL, or affected firmware version
- Operating system of involved components
- Version information
- Technical description of what actions were being performed and the result in as much detail as possible
- Sample code that was used to test or demonstrate the vulnerability
- Reporter’s contact information
- Other parties involved, if applicable
- Disclosure plans
- Threat/Risk assessment details of the identified threats and/or risk level (P1(Critical)P2(Severe) P3(Moderate)P4(low)P5(informational))
- Software configuration of the computer or device configuration at time of discovering the vulnerability
- Relevant information about connected components and when the vulnerability occurs (E.g., a secondary component or device triggers the vulnerability)
- Time and date of discovery
- Browser information including type and version information, if applicable
- Any evidence or indication that the vulnerability is being actively exploited, including observed dates, indicators of compromise, and observed impact
Risk Classification System
For the initial prioritization/rating of findings, this program will use the Bugcrowd Vulnerability Rating Taxonomy. However, in some cases, a vulnerability priority will be modified due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher along with the opportunity to appeal and make a case for a higher priority. Before submitting risk assessment information, please consider the severity breakdown we follow with Bugcrowd’s platform:
- P1 Critical: The issue identified in the submission has the highest priority and should be assigned to major blockers. Typically, submissions with a P1 priority classified as a major blocker cause the application to be unusable, has the potential to disrupt business operations, and require immediate attention.
- P2 Severe: This issue identified in the submission is not critical but significantly impacts the application.
- P3 Moderate: The submission does not present a critical or severe issue but does uncover a flaw in the application that needs to be fixed.
- P4 Low: This submission is the lowest priority and represents a minor issue.
- P5 Informational: This submission may provide suspicious information, but not conclusive if it poses any risk.
Digi’s internal priority ratings under this section are used for triage and remediation planning. They are separate from, and do not determine, whether an event meets the Article 14 thresholds for an actively exploited vulnerability or a severe incident described in the Regulatory Reporting section.
Prohibited Actions
The following actions are prohibited under this standard. Digi International reserves all legal rights if you engage in any of these prohibited activities.
- Testing on these subdomains: https://my.digi.com, https://shop.digi.com, https://partner.digi.com are strictly prohibited. Please review the program brief and reach out to Bugcrowd support with any questions.
- Opening support cases on our website is strictly prohibited. Please review the program brief and reach out to Bugcrowd support with any questions.
- Denial of Service (DoS) and Distributed Denial of Service (DDoS)
- If a vulnerability is discovered that may be able to perform a DoS or DDoS type of attack, please submit the information discovered but do not perform the attack.
- DoS testing against Digi International products owned solely by the researcher or customer is acceptable if it is on a network owned and operated by a researcher or customer.
- Spam reports or solicitation
- Phishing, vishing, spear phishing reports
- Social engineering reports
- Open ports with no accompanying demonstration or proof of concept of vulnerability
- Findings generated by automated tools without detailed explanation on what parts are vulnerable and how the vulnerability might be exploited