GB 44495-2024 sets the technical requirements for vehicle cybersecurity, and GB 44496-2024 sets the general technical requirements for automotive software updates. Both are mandatory national standards, released on 23 August 2024 and effective from 1 January 2026. New models under type approval must comply from the effective date; existing announced models get a transition period under MIIT's later arrangement rather than an instant block on every fresh project. The logic is close to UN R155 and R156, but China adds local requirements on cloud-vehicle interaction, data handling and identification management. BlueAsia works on connected-vehicle certification and reminds OEMs that these two are hard thresholds for new-vehicle projects within 2026 and must be scheduled into the project from the start.
2. Prepare Documents by Block
Neither standard goes through CCC. Testing is performed by a motor-vehicle inspection body authorised by MIIT with cybersecurity testing capability, and the results take effect with the whole-vehicle announcement — there is no separate standard certificate. Documents split into three blocks: cybersecurity, software update and sample-vehicle testing, all complete before sample submission.
Baseline Drafts to Prepare First
(1) Company qualifications. Business licence, legal-person status and basic credit files; the applying entity must match the later acceptance entity.
(2) Vehicle technical parameters. Whole-vehicle technical specification, electrical schematic and network architecture diagram, with versions matching the sample vehicle.
① A consistent applying entity front to back is the precondition for fewer rejections.
3. Cybersecurity Block Documents
GB 44495 emphasises both system and evidence chain. The CSMS file is the enterprise cybersecurity management-system manual plus supporting procedures, covering risk identification and handling across design, R&D, production, operation and scrapping. The TARA report is the threat-analysis and risk-assessment document — it cannot just state risk-mitigation conclusions; it must record the handling means and confirmation, so it is reviewable, and shallow analysis draws rejection. The enterprise also prepares a cybersecurity incident response plan and a vulnerability-management process; these two are system core items. The cybersecurity conformity declaration self-attests clause by clause against the standard, with test logs and screenshots attached.
4. Software-Update Block Documents
GB 44496 governs that the update process is traceable, verifiable and supports abnormal rollback. The SUMS process file spells out the software-update management process, version-management rules and fault-rollback handling plan. Update-package verification covers signature verification, run logs, power-loss abnormal-rollback evidence and pre/post-update vehicle-function consistency proof, showing that safety and driving functions do not degrade or fail because of the update. OTA pushes must keep complete records. The mechanism document for user notification and consent is also required, except for security-forced updates. Version numbers and update packages are managed separately, and rollback verification must close the loop.
5. Sample-Vehicle and Test Documents
The submitted vehicle runs security test cases on interfaces, permissions and communication links, and verifies update rollback. R155/R156 experience can reuse the document framework, but overseas test reports are not directly accepted — the local cloud-vehicle requirements must be retested, and the system files must add China-local differences including cloud-vehicle interaction security, data-export compliance, domestic cryptographic-algorithm support and identification management. Physical samples and document records that disagree are rejected outright; messy version management is a frequent problem. Inspection bodies run tight schedules, so locking the window early beats last-minute queue-jumping.
6. Version and Change Records
Keep version and change records from the R&D stage rather than writing them up the night before submission. Software, update-package and hardware version numbers are managed separately, and rollback verification must close the loop. After certification the item falls under whole-vehicle announcement production-consistency supervision, covered by routine CoP checks; system operation and supplier security-agreement compliance are audited, and serious deviation can suspend the certificate — this is not an annual audit set by these two standards alone. Among component suppliers, ordinary parts only submit a firmware-change ledger to the OEM; but key information-security components such as T-Box, gateway and domain controller must provide security design documents and test reports.
7. Linking to the EU Framework
The two regulations share design logic with R155 and R156, and the TARA framework is referenceable. But a model exported then re-imported cannot use the EU report directly; the domestic differences must be added. Picking an institution with experience on similar projects makes the document review go smoother.
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!
