GB 44495-2024, per the Amendment 1-scope clause, sets out the automotive information-security assurance requirements, the basic information-security requirements, the technical information-security requirements and the same-type determination, and describes the corresponding inspection and test methods — applicable to M-class and N-class vehicles. Those four blocks plus the test methods are the backbone of the text.
GB 44496-2024 has a different skeleton: software-upgrade assurance requirements, vehicle requirements, test methods, same-type determination, plus a baseline requirement for the user manual. It also has Amendment 1, in the same batch and effective 28 January 2026: the scope clause likewise deletes the O class and changes to "applies to M-class and N-class vehicles with software-upgrade capability"; "software upgrade management system requirement" is uniformly changed to "software upgrade assurance requirement". The two sit in parallel and do not cross-reference.
Chapter 5 is the information-security assurance requirement; 5.1 opens by stating the vehicle manufacturer shall meet the automotive information-security assurance requirements across the vehicle's full lifecycle. Note "full lifecycle" — R&D, production, operation and maintenance through to scrapping — not a system document handed in and done.
Chapter 6 ties the basic requirements to the development process: the vehicle-product development process must align with the assurance requirements. This is often missed in preparation — system and model are two lines, and this clause connects them. Use the clause numbers from the standard text itself; do not align with a testing body using a second-hand reading.
Chapter 8 is the inspection and test methods. 8.1 clearly splits into three categories: assurance-requirement inspection, basic-requirement inspection and technical-requirement testing. Do them separately; do not merge into one report.
Amendment 1 changed "information security management system" uniformly to "information security assurance requirement" and deleted the original 3.2 term. What the industry calls "no separate system certificate issued" refers to exactly this: the system is no longer an independent certification item; the material is a document inspection at the type-approval stage, on a separate line from the factory audit.
The term was shifted from "inspection" to "examination". On the surface it is a wording tweak, but in practice it shifts the material-list wording — the "inspection records" in old templates must follow the change.
One more easily missed: the amendment clarifies a three-year validity for the report under the same-type conditions. A derivative model on the same platform wanting to reuse the report must check whether it is still inside that three-year window.
Upgrade-package authenticity and integrity. The vehicle must identify a tampered package and refuse to execute it; signature verification and anti-replay must both be real.
The software identification code must be readable, updatable and tamper-resistant. A version number read from the diagnostic port that does not match the declared parameters fails outright.
User notification has specific elements: upgrade purpose, function-change description, estimated duration, functions unavailable during the upgrade, and safe-execution instructions. A bare "system upgrading" popup is not enough — there must be a confirmation screen, and execution is not allowed without confirmation.
Preconditions and power assurance. Before execution the vehicle state must be checked, with a clear power threshold that covers the redundancy for rollback after a failed upgrade; setting only a very low start-up interlock will not pass.
Door anti-lock is a distinctive clause in this version: during the upgrade the user must not be prohibited from unlocking the doors from inside. This is a hard domestic requirement, and export models often miss it.
The two standards were developed in close coordination with UN R155 and R156, with compatible broad frameworks. But the domestic version adds vehicle-cloud interaction, data export, identity marking and crypto compliance; using R155 evidence to cover it falls short.
Compared with R156, 44496 adds the test-methods chapter. R156 only says what should be done; the domestic version gives an operable verification guide, and testing bodies design tests against that chapter.
For these two standards, BlueAsia helps the client break the clauses into a material list first — which fall in documents, which need a test bench, and which must be evidenced on the cloud platform side — and for same-platform multiple models in parallel combines the sample vehicles, system files and same-type determination, covering in one pass what need not be repeated.
Do not read "no independent certificate" as "no requirement". Both standards hang on the vehicle-market-access stage; if the report fails, the model cannot reach the announcement.
Online readings of these two standards often treat the clause numbers of the draft-for-comment as the current ones, copying terms that have already been changed. These pages with distorted information tend to rank poorly — check against the standard text itself before writing your material.
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
