China's three mandatory automotive national standards — GB 44495-2024, GB 44496-2024 and GB 44497-2024 — were officially published on 23 August 2024. With the amendment sheet, the compulsory type-approval node for new vehicle models is 2026-07-01; as the first batch of strong standards for China's intelligent-connected vehicles, every later new-model project must meet them.
Scope
GB 44495 applies to M-class, N-class and O-class vehicles with at least one electronic control unit. GB 44496 targets M, N, O vehicles capable of software upgrades. GB 44497 is the automated-driving data-recording system and is a separate standard entirely.
Drafting logic
The standards borrow the overall framework of UN R155 and R156 and coordinate with overseas regulations, while adding China-specific controls: cloud-vehicle interaction, data handling, identity marking and cryptography compliance. Simply copying overseas test documents cannot satisfy the domestic submission requirements.
No standalone standard certificate
Neither standard falls under CCC. Testing is done by an institution qualified for automotive information-security testing, and the results are folded into the whole-vehicle announcement. A company cannot obtain a separate GB 44495 certificate; align expectations early to avoid acceptance disputes later.
2. What GB 44495 tests
Information-security management review
Benchmarked to the UN R155 CSMS mindset, it reviews risk identification and treatment across the vehicle lifecycle — R&D, production, operation and maintenance through to scrap. The focus is whether the system is actually running, not just whether paperwork was submitted. China does not issue a separate CSMS certificate; the review rides along with the whole-vehicle announcement.
External-connection security
Interfaces such as OBD, USB, Bluetooth, Wi-Fi and cellular are all reviewed. Core checks: interface authentication, anti-unauthorised-access protection, and control of debug interfaces at mass-production stage. The mass-production debug interface need not be physically removed, but it must not leave an unprotected external-access path — proper authentication is enough. Wireless interfaces are a high-risk spot; a leftover uncontrolled path on the debug port is a very common deduction in actual testing.
Communication security
It assesses in-vehicle CAN and automotive-Ethernet message authentication and integrity, plus encryption and identity verification for vehicle-cloud transmission. Vehicles with V2X also need an external-communication protection assessment.
Software-upgrade security
This links with GB 44496 content, reviewing upgrade-package signature verification, anti-rollback and upgrade-failure protection capabilities.
Data security
It implements data-collection minimisation, local-storage protection, data-export compliance, and personal-information protection and deletion mechanisms. This must align with cybersecurity and data-security regulations, with security and legal teams working together.
Inspection and test methods
It is not only document review; real vehicles or benches are used for verification. In practice, labs run interface, permission and communication-link security checks. "Penetration testing" is the testing institution's working term — the standard text itself does not use that phrase. Same-type determination is also performed to define which derivative models need retesting.
3. What GB 44496 tests
Software-upgrade management system
SUMS reviews the process, role responsibilities, version control and failure-rollback plan, with retrievable execution records kept.
User notification and version read
It defines the content and form of pre-upgrade notification; even a safety-force-update must still notify and state the reason. The whole-vehicle software version must support external reading for regulator verification.
Safety protection and upgrade prerequisites
It verifies upgrade-package authenticity and integrity against tampering. The cryptography algorithm must comply with commercial-cryptography regulations — this does not mandate a domestic SM algorithm. If vehicle-speed, gear or battery conditions are not met, the upgrade must not start.
Power assurance and abnormal-failure handling
It defines the logic for insufficient battery, and requires rollback recovery after power loss or transfer interruption, with evidence of whole-vehicle functional consistency before and after the upgrade.
Product manual
The standard explicitly requires a product user manual — an easily overlooked part of the sample package.
4. Document-preparation points
·Materials split into three blocks: information security, software upgrade and sample-vehicle testing. Incomplete materials and the testing institution will not accept the case.
·Information-security block: system documents, TARA risk-assessment report, incident-response plan, vulnerability-management process, and clause-by-clause self-evidence. TARA reports have a high rejection rate — do not just write conclusions; record the risk-treatment measures in full.
·Software-upgrade block: SUMS process documents, upgrade-package verification data, abnormal-rollback evidence, user-notification materials, and complete OTA push logs.
·Version-change records must be kept continuously from the R&D stage; do not patch them together right before submission.
5. Component-supplier division of labour
·Firmware-change ledgers for ordinary components are more an OEM supply-chain control requirement; the national standard does not directly compel component companies.
·Key security parts such as T-Box, gateway and domain controller must produce security-design documents and test reports. BlueAsia handles component projects by prioritising TARA and security-design documents first, reducing the chance of document gaps at whole-vehicle submission.
·EU R155/R156 test reports cannot be taken at face value; the document framework can be referenced, but local requirements like cloud interaction and data compliance must be re-verified.
6. High-frequency deduction points
·A sample whose software/hardware state disagrees with the submitted documents is rejected outright; messy software-version management is a very common problem.
·Qualified testing institutions are limited in number; lock the schedule early rather than rushing near the node.
·There is no standalone 44495/44496 certificate; the constraints feed into the whole-vehicle announcement's production-consistency supervision. A serious non-conformity affects the whole-vehicle announcement, not a separate suspension of these two standards.
Contact: King Email: king.guo@cblueasia.comAddress: Building C, Hongjingda Industrial Park, No. 107 Beihuan Road, Shiyan Street, Bao'an District, Shenzhen, China BlueAsia delivers more than service!
Related News
