Product Security Vulnerability Disclosure Policy
Policy Statement
TSC Auto ID is committed to providing secure and reliable products and services while continuously enhancing product cybersecurity resilience. To assist customers, users, cybersecurity researchers, partners, and other stakeholders in reporting potential security vulnerabilities affecting our products, we have established a Product Security Incident Response Team (PSIRT) responsible for receiving, evaluating, verifying, remediating, and disclosing product security vulnerabilities.
We adopt a Coordinated Vulnerability Disclosure (CVD) mechanism, collaborating with vulnerability reporters and relevant stakeholders to minimize the risk of vulnerabilities being maliciously exploited and to protect the information security of all users.
Scope of Application
This policy applies to products and services developed, maintained, sold, or within their support period by TSC Auto ID, including but not limited to:
- Hardware
- Firmware
- Software
- Network devices
- Management interfaces
- APIs and communication protocols
- Cloud services
- Mobile applications
- Update and maintenance tools
- Products integrated with third-party and open-source components
Product versions that have reached the end of their security support are generally excluded from this policy; however, we may still evaluate actual risks to determine whether to accept a report on a case-by-case basis.
Vulnerability Handling Process
The Company's vulnerability management process consists of the following steps:
- Step 1: Receipt and Registration
A case number is generated and tracked upon receiving a vulnerability report.
- Step 2: Vulnerability Verification
Confirm whether the vulnerability is reproducible and affects supported products and versions.
- Step 3: Risk Assessment
Comprehensive evaluation based on:
• CVSS severity score
• Exploitability
• Availability of public PoC (Proof of Concept)
• Evidence of active exploitation
• Impact scope
• Regulatory and customer impact
• To determine remediation priorities.
- Step 4: Remediation and Testing
Following patch development, the following procedures are executed:
• Patch verification
• Regression testing
• Security testing
• Update integrity verification
• Ensuring that no new security risks are introduced
- Step 5: Announcement and Disclosure
Publish a Security Advisory at an appropriate time, providing:
• Vulnerability description
• Affected products
• Patched versions
• Mitigation measures
• Update instructions
• Where necessary, coordinated disclosure will be conducted with third-party vendors, CERTs/CSIRTs, or other stakeholders
Responsible Disclosure Principles
The Company encourages good-faith and responsible security research and expects reporters to:
- Comply with applicable laws and regulations
- Conduct testing strictly within the bounds of lawful authorization
- Refrain from accessing, modifying, or deleting data belonging to others
- Avoid performing Denial of Service (DoS) or destructive testing
- Avoid engaging in social engineering or phishing attacks
- Keep technical details confidential until remediation is complete
The Company commits that it will not take unnecessary legal action against researchers for good-faith and responsible vulnerability submissions.
Response Timeline Targets
The Company generally aims to adhere to the following target service timelines:
| Item | Target Timeframe |
|---|---|
| Acknowledgment of Receipt | Within 3 business days |
| Initial Validity Assessment | Within 10 business days |
| Severity Assessments | Within 15 business days |
| Status Updates | Every 14 to 30 days |
| Public Disclosure | Once patches or workarounds are available |
Note: Actual timeframes may vary depending on vulnerability complexity, product impact scope, and third-party coordination requirements.
Policy Maintenance
This policy is reviewed at least annually and updated appropriately under the following circumstances:
- Changes in regulations or standards
- Changes in product types
- Occurrence of major security incidents
- Improvements needed in the vulnerability handling process
The latest version will be posted on the Company's official website.
Disclaimer: Various aspects of information security vulnerability management principles may be subject to change on a case-by-case basis. The Company does not guarantee a response to any specific inquiry or issue. Use of the information contained within this document or links provided herein is at your own risk. The Company reserves the right to modify any content within this policy at any time without prior notice. Any modifications will be published on the Company's official website.

































