Nozomi Networks Product Security Incident Response Team (PSIRT) is responsible for investigating security concerns that potentially affect our products and services. This Coordinated Vulnerability Disclosure (CVD) policy describes how external security researchers, customers, coordinators, and members of the public can report potential vulnerabilities to Nozomi Networks and what they can expect from us throughout the process.
This policy is aligned with prEN 40000-1-3 (Cybersecurity requirements for products with digital elements, Part 1-3: Vulnerability Handling), EN ISO/IEC 29147 and EN ISO/IEC 30111, and supports Nozomi Networks' vulnerability handling obligations under Regulation (EU) 2024/2847 (Cyber Resilience Act). The applicability of requirement enhancements defined in prEN 40000-1-3 is determined through a documented, risk-based assessment maintained by the Product Security organization.
This policy is publicly available on this portal, is reviewed at least annually, and is updated whenever significant changes occur to our products, processes, or regulatory environment.
Scope
Products in scope
This policy applies to all currently supported Nozomi Networks products and services, including:
- N2OS and the appliances running it (Guardian, Central Management Console, Remote collector)
- Vantage and Vantage IQ
- Arc and Arc Embedded
- Guardian Air
- Threat Intelligence and Asset Intelligence feeds
Out of scope
- Products or product versions that have reached end of life or end of support
- Third-party products, services, or infrastructure not owned or operated by Nozomi Networks
- The corporate website, customer-facing portals and marketing infrastructure (issues affecting these can still be reported and will be routed internally, but are handled outside this policy)
Nozomi Networks aims to address vulnerabilities found in our products according to the following timeline:
For on-prem products:
- Critical/high vulnerabilities will be remediated within 2 months.
- Medium/low vulnerabilities will be remediated within 6 months or in the next release, whichever comes first.
For SaaS products:
- Critical/high vulnerabilities will be fixed within 30 calendar days.
- Medium/low vulnerabilities will be fixed within 6 months.
Certain parts of the Nozomi Networks operating system may include third-party software. Nozomi Networks monitors disclosures regarding security incidents involving third-party software and conducts due diligence to ensure patches are incorporated into the Nozomi Networks operating system within 30-60 days of their release. If a third-party software vulnerability lacks an officially released patch, Nozomi Networks may choose to mitigate the vulnerability if necessary or wait until an official patch is available.
How to Get in Touch
Nozomi Networks provides two channels for reporting a potential vulnerability. Both reach the PSIRT directly and both encrypt your report end-to-end with the PSIRT public key, so you can use whichever is more practical for you. Please do not report vulnerabilities through public channels such as social media, public code repositories, or ordinary support tickets.
Encrypted email
Send your report to prodsec@nozominetworks.com, encrypted with the PSIRT GPG key. The same key is published as the Encryption entry of our security.txt. Use this channel if you already work with GPG, or if you want your report to reach us without transiting any intermediary.
Secure web form
Submit your report through our contact form. Your message and every file you attach are encrypted in your browser with the PSIRT public GPG key before they leave your device, so only the holder of the PSIRT private key can read them. Use this channel if you would rather not set up GPG tooling yourself: it gives you the same end-to-end protection as encrypted email without requiring you to install or configure anything. The only fields transmitted in plaintext, over HTTPS, are your name and email address, which we need in order to acknowledge your report and reply to you.
Reporters who wish to remain anonymous may do so by email, using an address that does not identify them; the web form asks for a name and an email address so that we can acknowledge the report and follow up. Please note that anonymity may limit our ability to provide follow-up communication, coordinate disclosure, or credit you in an advisory.
What to include in your report
To enable efficient triage, please provide where possible:
- Affected product(s), version(s), and configuration details
- A description of the vulnerability and its potential impact
- Step-by-step instructions to reproduce the issue, including any tools used
- Supporting evidence such as screenshots, network captures, logs, or proof-of-concept code
- A suggested CVSS score or severity assessment (optional)
- Contact details for follow-up communication (optional if reporting anonymously)
If the report does not contain sufficient information to reproduce the issue, we will contact you to request additional details. A working proof of concept is appreciated but not required to submit a report.
What to Expect After You Report
Nozomi Networks follows a structured vulnerability handling process aligned with prEN 40000-1-3, consisting of receipt, verification, remediation, release, and post-release phases. You can expect the following communication throughout the process:
- Acknowledgement. We will acknowledge receipt of your report within 3 business days. The acknowledgement will include a unique tracking number logged in our support system.
- Verification. Our PSIRT will assess and attempt to reproduce the reported issue. We will inform you of the outcome of the verification, including whether the issue is confirmed as a vulnerability, within 15 business days of acknowledgement.
- Risk assessment. Confirmed vulnerabilities are assessed using CVSS v4.0 together with a documented, risk-based evaluation that considers exploitability, required access, exposure of the affected component, and impact on confidentiality, integrity, and availability. The assessment determines affected products and versions, assigns a severity level, and drives remediation priority. The assessment is revisited if new information becomes available, such as changes in exploitability or public exploit availability.
- Status updates. For confirmed vulnerabilities, we will provide status updates at least every 30 days until remediation, and we will notify you in advance if a remediation target cannot be met, together with a revised timeline and interim mitigation guidance where available.
- Resolution. We will notify you when the vulnerability has been remediated and coordinate publication with you as described below.
Remediation and Testing
Remediations are developed according to the timelines stated above. Before release, every security fix is tested to verify that it effectively remediates the vulnerability and does not introduce regressions. Testing includes reproduction of the original issue against the fixed build, automated regression testing, and internal vulnerability assessment of the release candidate. Evidence of remediation testing is retained as part of our vulnerability handling records.
Nozomi Networks also performs regular, risk-based security tests and reviews of its products in accordance with a documented internal Security Test and Review Plan. This includes automated static and dynamic analysis, dependency and container scanning on every build, internal vulnerability assessments on nightly builds, and recurring penetration tests performed by internal teams and independent third parties.
Coordinated Disclosure and Security Advisories
Nozomi Networks supports coordinated public disclosure. For externally reported vulnerabilities, prior to public disclosure we will seek agreement with the reporter on the disclosure date, the content of the advisory, and any embargo period required to protect users. Our target coordinated disclosure window is 90 calendar days from acknowledgement; if this window cannot be met, we will notify the reporter and agree on a revised date. Nozomi Networks reserves the right to disclose vulnerability information without the reporter's involvement where necessary to protect users or to comply with legal obligations.
Once a fixed version is available, a security advisory is made available to customers on this portal without undue delay. Because Nozomi Networks products are deployed in operational technology and critical infrastructure environments where upgrade cycles are constrained, full public disclosure of technical details may be deferred by up to 90 days after the release of the fixed version, to ensure customers have adequate time to upgrade before details become public. This deferral is a deliberate, risk-based measure to protect users of the affected products.
Each advisory includes:
- A description of the vulnerability and its CVE identifier where applicable
- The affected products and versions, allowing users to identify whether they are impacted
- The severity (CVSS v4.0 score and vector) and impact of the vulnerability
- Clear and accessible instructions for remediation, including fixed versions and, where available, workarounds or mitigations
Advisories are published in human-readable format on this portal and, wherever applicable, in machine-readable CSAF format. A CSAF trusted provider metadata file is also available. An RSS feed is available for notification of new advisories.
In addition, as a CNA, Nozomi Networks has the authority to assign unique CVE identifiers to track vulnerabilities specific to our products.
What "Vulnerable" Means to Us
All reported issues are evaluated using a risk-based assessment process. Nozomi Networks considers factors such as the potential impact on confidentiality, integrity, and availability of systems or data; the level of access required to exploit the issue; the likelihood of exploitation; the exposure of the affected component; and whether the issue can be reliably reproduced.
Issues determined to pose a material security risk will be prioritized for remediation in accordance with Nozomi Networks’ vulnerability management process.
Not all vulnerable code exposes an exploitable or attackable vulnerability. Our system image ships with already hardened configurations because we do our best to protect our customers. Moreover, our QA system regularly scans our code base, and we conduct an internal vulnerability assessment on every nightly build.
Usually, vulnerabilities must load and execute some code on the local system. Our system image design disallows the addition of system users to the console. This means that in order to execute local code inside our system image, an attacker must already have complete access to the system.
Code of Conduct and Rules of Engagement
We kindly request that you adopt the principles of responsible disclosure and notify us of any security issues affecting our products before disclosing them publicly, so that we can promptly resolve any vulnerabilities.
While we do not currently operate a bug bounty program, we appreciate responsible disclosure and may acknowledge researchers in our advisories with their consent. Please note that we do not consider findings originating from SSL/TLS scanners or port scanners, low-level configuration issues such as cookie flags or security headers, or potential vulnerabilities with no actual impact to be vulnerable. Please refer to the sections What "Vulnerable" Means to Us and Out-of-Scope Vulnerabilities for further details.
Furthermore, we kindly request that you do not perform DoS/DDoS attempts on production systems or engage in unauthorized social engineering attacks. In the event that you are able to access PII or other sensitive data through a vulnerability, please stop immediately, and report it to us without extracting any further data.
If you conduct security research in good faith and in accordance with this policy, Nozomi Networks considers such activity to be authorized and subject to safe harbor. Nozomi Networks will not pursue legal action or refer the matter to law enforcement for accidental or good-faith violations of this policy, provided that you avoid privacy violations, service disruption, or data destruction, access only the minimum information necessary to demonstrate a vulnerability, and promptly report the issue through the designated reporting channels.
Confidentiality
Vulnerability reports are treated as confidential. Nozomi Networks will not share personal information provided by reporters with third parties without explicit consent, except where required by law. Vulnerability details are shared internally on a need-to-know basis until a fix is available and disclosure is coordinated. Reports sent through the web form are relayed by a third-party form-processing provider acting on our behalf. Because the report body and its attachments are encrypted in the reporter's browser, that provider only ever handles ciphertext it cannot read; the reporter's name and email address are the only report data visible to it.
Reference
CVE Risk Level mapping
| CVE Level | CVSS v4.0 |
|---|---|
| Critical | 9.0–10.0 |
| High | 7.0–8.9 |
| Medium | 4.0–6.9 |
| Low | 0.0-3.9 |
Impact Reference
DoS, Code Execution, Overflow, Memory Corruption, SQL Injection, XSS, Directory Traversal, HTTP, Response Splitting, Bypass something, Gain Information, Gain Privileges, CSRF, File Inclusion
Out-of-scope vulnerabilities
At its sole discretion, Nozomi Networks may deprioritize findings that do not pose a demonstrable security impact.
The following is a list of out-of-scope vulnerabilities that will not be considered for remediation. These vulnerabilities do not pose a significant risk to the application's security and are considered low-impact or not relevant to the scope of the project.
- Anything reported by automated web vulnerability scanners, SSL/TLS scanners, or port scanners.
- Any credentials or personal information that are automatically saved or filled in by the user's browser or client-side application.
- Low-impact disclosures, and banner-grabbing issues.
- Issues related to password and credential strength, such as insufficient length, lack of lockouts, or inadequate brute-force/rate-limiting protections.
- Errors in user interface and user experience, such as spelling mistakes.
- Missing cookie flags, unless they directly lead to a security vulnerability.
- Cross-site Request Forgery (CSRF) vulnerabilities with a low-security impact, such as logout CSRF.
- Self-XSS and clickjacking.
- Missing X-Frame-Options header (Clickjacking/UI Redressing).
- Security vulnerabilities that only affect older user agents or application versions.
- SSL/TLS mixed content issues unless they result in the leakage of sensitive information such as cookies and credentials.
- Lack of SSL/TLS or SSL/TLS best practices that do not contain a fully functional proof of concept.
- Host header open redirects.
- Minor issues regarding session management, such as concurrent sessions, session expiration, and session refresh upon password reset/change or log out.
- HSTS or CSP headers
- Path, information or version disclosure
- Issues requiring administrative privileges or intentional misconfiguration by privileged users.
Policy Review
This policy is reviewed at least annually by the Product Security team, or earlier following significant changes to Nozomi Networks products or the regulatory environment.
| Version | Date | Description of change |
|---|---|---|
| 2.0 | 2026-09-10 | Alignment with prEN 40000-1-3 and the Cyber Resilience Act: added scope, communication expectations, two end-to-end encrypted reporting channels (encrypted email and secure web form) replacing unencrypted email, anonymous reporting, risk assessment and remediation testing statements, coordinated disclosure procedure, confidentiality, policy review |
| 1.4 | 2026-04-08 | Retitled to Vulnerability Disclosure Policy; added 72-hour review commitment, risk-based "Vulnerable" assessment criteria, and safe-harbor clause; expanded Code of Conduct |
| 1.3 | 2024-05-28 | Adopted CVSS v4.0 for CVE risk-level mapping |
| 1.2 | 2023-09-22 | Split remediation timelines into on-prem and SaaS with per-severity SLAs; renamed lowest risk tier from "Informational" to "Low" |
| 1.1 | 2023-04-14 | Added "What Vulnerable Means to Us", Code of Conduct and Rules of Engagement, CNA/CVE authority statement, CSAF availability, out-of-scope vulnerabilities list, and 90-day advisory deferral |
| 1.0 | 2020-07-07 | Initial policy publication |