Hexing Electrical Co., Ltd. Coordinated Vulnerability Disclosure Policy

1. Purpose

Hexing Electrical Co., Ltd. (hereinafter “the Organization”) is committed to ensuring the security of its products with digital elements, in accordance with the EU Cyber Resilience Act (Regulation (EU) 2024/2847).

This Coordinated Vulnerability Disclosure (CVD) Policy establishes the process by which external security researchers, customers, suppliers, coordinators, and members of the public may report potential security vulnerabilities affecting the Organization’s products, and defines the Organization’s commitments regarding the handling and disclosure of such vulnerabilities.

This policy is designed in alignment with prEN 40000-1-3:2025 (Network security requirements — Vulnerability handling), which establishes requirements and recommendations for manufacturers of products with digital elements on the handling and disclosure of potential vulnerabilities.

2. Definitions

3. Scope

• All products (digital elements) manufactured or distributed by Hexing Electrical Co., Ltd. that fall within the scope of the EU Cyber‑Resilience Act
• All software and hardware components integrated into these products, as documented in SBOM and HBOM

3.1 In-Scope Products and Services

The following products, systems, and services are within the scope of this policy:

• HXE110、HXE310、HXF300、HXEJ200

3.2 Out-of-Scope

The following are explicitly excluded from this policy:

• Third-party products, services, or infrastructure not owned or operated by the Organization
• Social engineering, phishing, or physical security attacks
• Denial of Service (DoS) or Distributed Denial of Service (DDoS) attacks
• Vulnerabilities in end-of-life products no longer supported by the Organization
• Issues already known to the Organization or previously reported and under active remediation
• Any additional exclusions specific to the Organization

4. Roles and Responsibilities

4.1 Product Security Incident Response Team (PSIRT)

The designated internal team responsible for managing vulnerability disclosures is the Product Security Incident Response Team (PSIRT). This team is responsible for:

• Receiving and acknowledging vulnerability reports
• Triaging, investigating, and prioritising reported vulnerabilities
• Coordinating remediation efforts with relevant internal teams and, where applicable, upstream stakeholders
• Communicating with the reporter throughout the process
• Publishing advisories or notifications where appropriate
• Maintaining records of all handled vulnerabilities

4.2 Reporter

Any individual or organisation that identifies and submits a potential vulnerability. Reporters are expected to:

• Act in good faith and adhere to the terms of this policy
• Avoid unauthorised access to, or modification of, data or systems
• Not disclose the vulnerability publicly before the Organization has had a reasonable opportunity to remediate it
• Provide sufficient detail to allow the Organization to reproduce and validate the issue

5. How to Report a Vulnerability

5.1 Submission Channels

Vulnerability reports should be submitted through the following channel(s):

PGP Key Fingerprint: key ID 0x4BCC88B9; PGP fingerprint: 70C5 F1C4 6F2D 1B07 58BF F88A 3523 DD3E 4BCC 88B9

5.2 Information to Include

To enable efficient triage, reporters should provide the following information where possible:

1. Affected product(s): Product name, version(s), platform, and/or URL(s)
2. Vulnerability description: Detailed description of the vulnerability and its potential impact
3. Reproduction steps: Step-by-step instructions, including tools and environment details, to reproduce the vulnerability
4. Supporting evidence: Screenshots, network captures, logs, or Proof-of-Concept (PoC) code
5. Severity assessment: Suggested CVSS v3.1 or v4.0 score (optional)
6. Contact details: Email or other contact information for follow-up communication

5.3 Anonymous Reporting

Reporters may submit vulnerabilities anonymously. However, anonymity may limit the organisation’s ability to provide follow‑up communication or recognition.

6. Vulnerability Handling Process

The Organization follows the vulnerability handling process as defined in prEN 40000-1-3, consisting of the following phases:

6.1 Receipt

Upon receipt of a vulnerability report, the Organization will:

• Acknowledge receipt within 7 business days
• Assign a unique tracking number (Description: The product type for electricity meters is METER. VUL stands for vulnerability identifier, YYYY denotes the year, and XXXX is a four‑digit vulnerability number. Duplicates are not allowed.
  Example: METER‑VUL‑2026‑0001)
• Provide the reporter with an initial point of contact within the PSIRT

6.2 Verification

Upon acknowledgement, the PSIRT will assess the report within 15 business days. During this phase, the Organization will:

• Validate the vulnerability and attempt to reproduce it
• Assess severity using CVSS v3.1 or v4.0 scoring
• Determine affected product(s) and version(s)
• Assign an internal priority based on risk assessment

If the report does not contain sufficient information to reproduce the vulnerability, the PSIRT will contact the reporter to request additional details.

6.3 Vulnerability Risk Assessment

Following verification, a risk assessment is conducted to determine the potential impact and priority:

The reporter will be informed of the verification results and the assigned priority level.

6.4 Remediation

The Organization will develop and test a remediation or mitigation for validated vulnerabilities. Remediation options include:

• Security patch: A software update that directly fixes the vulnerability
• Configuration change: A change in product configuration that mitigates the vulnerability
• Mitigation guidance: Interim guidance for users to reduce risk pending a full fix
• End-of-life notification: Where a product is no longer supported, users will be notified

Where a fix cannot be delivered within the target timeframe, the Organization will notify the reporter with a revised timeline and interim mitigation guidance.

6.5 Remediation Testing

Before release, all remediations undergo:

• Functional testing to verify the fix addresses the vulnerability
• Regression testing to ensure no negative impact on product functionality
• Compatibility testing across affected product versions

6.6 Release and Disclosure

Once remediation is complete, the Organization will:

1. Notify the reporter that the vulnerability has been resolved
2. Publish a security advisory or release note as appropriate
3. Credit the reporter (if consent is provided) in any public advisory
4. Update the product’s security documentation

The Organization supports coordinated public disclosure. Prior to any public disclosure, both parties should agree on:

• The disclosure date
• The content of any public advisory or statement
• Any embargo period required to protect users

NOTE: Different embargo periods may be negotiable on a case-by-case basis between the Organization and the reporter, or a coordinator if involved.

The Organization targets a coordinated disclosure window of no more than 120 calendar days from the date of acknowledgement. If this window cannot be met, the reporter will be notified and a revised date agreed upon.

6.7 Post-Release Actions

Following the release of a security update, the Organization will:

• Monitor for any issues related to the released remediation
• Verify that the vulnerability has been effectively addressed
• Update the vulnerability record with the final status
• Conduct lessons-learned reviews for significant vulnerabilities

7. Secure Communication

7.1 Supported Secure Communication Methods

7.2 Operational Security

All non-public vulnerability information is treated as confidential. Access is restricted to authorized PSIRT members and relevant stakeholders on a need-to-know basis. Information may be classified using the Traffic Light Protocol (TLP):

8. Ongoing Communication

The Organization commits to maintaining regular communication with reporters and stakeholders throughout the vulnerability handling process:

• Acknowledgement: Within 2 business days of receipt
• Status updates: At least every 30 calendar days during active handling
• Verification results: Provided after initial assessment is complete
• Remediation timeline: Communicated upon completion of risk assessment
• Resolution notification: Provided when the remediation is released
• Public advisory: Published through the Organization’s security channels

Communication channels include email, web portal, and other accessible modes as appropriate.

9. Confidentiality

The Organization will treat vulnerability reports with confidentiality and will not share personal information provided by reporters with third parties without explicit consent, except where required by law.

Non-public vulnerability information will be handled in accordance with the operational security measures defined in Section 7.2.

Reporters who wish to remain anonymous may do so; however, anonymity may limit the Organization’s ability to provide follow-up communications or recognition.

10. Contact Information

11. Policy Management

11.1 Review and Updates

This policy will be reviewed at least annually or following any significant change to the Organization’s products, regulatory environment, or threat landscape. Updates will be published on the Organization’s website and communicated internally.

11.2 Exceptions

Any exceptions to this policy must be formally approved by the document owner and documented in the exceptions register. Exceptions are time-limited and subject to annual review.

11.3 Compliance Evidence

The Organization maintains the following evidence to demonstrate compliance with this policy and prEN 40000-1-3:

• Published CVD policy (this document)
• Evidence of contact mechanisms being publicly accessible
• Records of acknowledged reports with tracking numbers
• Documentation of verification and risk assessments
• Remediation plans and timelines
• Remediation test reports
• Published security advisories
• Records of communication with reporters and stakeholders

Appendix A: Vulnerability Report Template

Reporters may use the following template when submitting a vulnerability:

Appendix B: Document Revision History

Appendix C: Alignment with prEN 40000-1-3

This table maps the sections of this CVD policy to the relevant requirements in prEN 40000-1-3:2025.