For vehicle OEMs and component suppliers, these two mandatory standards are non‑negotiable for new domestic vehicle projects in 2026. GB 44495 covers vehicle cybersecurity – GB 44496 covers software‑update management. Both are mandatory test items for vehicle type approval.
GB 44495 requires the establishment of a CSMS (Cybersecurity Management System) – covering risk identification and handling across vehicle‑side, cloud‑side, and communication links. GB 44496 governs the full software‑update process – updates must be traceable, verifiable, and support exception rollback.
From 1 July 2026, new type‑approval applications for passenger and commercial vehicles must comply with both standards. Existing models have a transition period – but new projects have no buffer – both standards must be incorporated into the overall plan from the start.
The two standards are conceptually similar to EU R155/R156 – but implementation requirements differ. China adds local requirements for vehicle‑cloud interaction, data handling, and labelling. Export‑to‑domestic models cannot directly use EU reports – local differences must be supplemented. Clarifying the applicable boundaries early reduces later rework.
2. Choose an MIIT‑Recorded Test Body
These two standards are not part of CCC certification. Testing is conducted by MIIT‑recorded vehicle inspection bodies – results take effect with the vehicle announcement – there is no separate standard certificate.
Select a body early – submit application documents – complete document review, technical assessment, and vehicle testing – reusing existing vehicle factory‑audit processes.
Different bodies have different capabilities, scheduling, and specialities. Don't wait until samples are ready to compare and select. Choose a body with practical experience in similar projects – their document interpretation will be closer to review requirements – reducing supplementary submissions. Only after receiving the body's acceptance letter can you schedule tests – advance this step.
3. Complete Full Documentation Before Sample Submission
Core documents:
·Vehicle CSMS system documentation.
·TARA (Threat Analysis and Risk Assessment) report.
·Cybersecurity declaration of conformity.
·Software‑upgrade management processes, version management rules, and rollback plans.
Documentation requires a complete evidence chain – not just document stacking. Maintain version and change records during R&D – avoid last‑minute document assembly. Version‑management confusion is a common issue – mismatches between samples and documentation cause direct rejection. TARA reports must include not just risk‑mitigation conclusions – but also specific measures and verification records – ensuring reviewability.
4. Lab Testing – Key Points
GB 44495 tests interfaces, permissions, and communication‑link security cases. GB 44496 verifies upgrade‑package signatures, operational logs, and power‑failure rollback functionality.
Projects with R155/R156 experience can reuse the document framework – but overseas test reports cannot be directly accepted – China‑specific requirements (e.g., vehicle‑cloud communication) must be supplemented. Lab scheduling is tight – secure slots early. Run internal pre‑testing before formal testing – identifying software/hardware issues early – reducing formal‑test remediation rounds.
5. Factory Audit – Important Notes
There is no separate factory audit for these two standards – they are embedded in the existing vehicle‑announcement factory‑audit process. The audit focuses on system implementation – covering production consistency, software‑flash controls, critical‑component change records, and training records.
Many companies pass testing – but fail on‑site audits due to missing operational records – extending timelines. Conduct an internal pre‑audit before the formal audit – check against the audit checklist – complete all records – aim for a first‑time pass – avoiding remediation delays.
6. Overall Timeline Breakdown
Stage Duration
System building + documentation 4–8 weeks
Vehicle testing 4–8 weeks (affected by remediation rounds)
Document review + announcement filing 2–4 weeks
·Mature platforms with existing CSMS/SUMS systems: total ~3 months.
·New platforms: typical 3.5–6 months.
The biggest variables are document rework and test remediation. New projects must reserve buffer – don't schedule too tightly.
7. Common Pitfalls
·TARA analysis is superficial – lacking implementable evidence.
·Software/hardware version labelling is inconsistent – upgrade rollback validation cannot be closed.
·Vehicle‑cloud localisation items are missed – requiring supplementary testing.
Manage software, upgrade‑package, and hardware version numbers separately – keep complete upgrade records. Vehicle‑cloud compliance cannot be just verbal – documentation and product architecture must both have evidence – don't take chances.
8. Relationship with UN R155/R156
The two regulatory frameworks share design logic – TARA analysis frameworks from R155 projects can be referenced. However: overseas certificates and test reports cannot be directly used for domestic announcement applications.
We recommend preparing a China‑EU standard difference comparison table – reusing document frameworks where possible – supplementing China‑specific requirements – reducing document workload and rejection risk. The table can also be reused for subsequent changes and annual audits.
9. Practical Timeline Control Recommendations
Run system building and vehicle development in parallel. Start TARA analysis at the project‑definition stage – don't wait until design is frozen. Book test bodies and slots early – submit complete documents in one go.
Embed compliance work into development milestones – not as a post‑development add‑on. Assign a dedicated person to track progress – with regular status updates. Keeping systems and development aligned stabilises project milestones – reducing last‑minute firefighting.
For GB 44495/44496 certification, contact BlueAsia at 13534225140 (King) or email king.guo@cblueasia.com.
Related News
