GB 44495 vs UNECE R155: What Changes for OEMs Entering China

If you sell new vehicles into China, you will need to demonstrate compliance with GB 44495 — China’s mandatory national standard for vehicle cybersecurity. The standard was published by SAC (Standardization Administration of China) in 2024 and is being phased into MIIT (Ministry of Industry and Information Technology) vehicle type-approval requirements through 2026–2028. Always verify the current effective dates against the latest MIIT vehicle-product announcement (公告) before submitting — the schedule is gazetted via MIIT bulletins, not the standard text itself.

If you already comply with UNECE R155 in the EU, Japan, or South Korea, GB 44495 looks superficially similar — both require a Cybersecurity Management System (CSMS) at the organizational level, a Threat Analysis and Risk Assessment (TARA) at the vehicle-type level, and ongoing post-production monitoring. The two standards explicitly draw on the same intellectual lineage: WP.29 R155 + ISO/SAE 21434.

The differences sit in the details — threat catalog, evidence formats, accepted certifying bodies, data-residency expectations, China’s MIIT vehicle-product type-approval flow (车辆产品准入), and post-market reporting. This article walks through what an OEM with mature R155 compliance must redo, can reuse, and should plan around when entering or expanding in China.

TL;DR for the impatient

• GB 44495 is China’s mandatory national standard for vehicle cybersecurity. Phased into MIIT type approval through 2026–2028; the operative dates are set by MIIT 公告 (announcement), not the standard text. Verify before each submission.
• It is aligned with R155 + ISO/SAE 21434 in structure, but is not equivalent. Mutual recognition is not in place; an EU type-approved vehicle still needs a separate Chinese assessment.
• The CSMS process documentation can be largely reused; the TARA artifacts can be largely reused; the threat catalog mapping needs a Chinese-context overlay; the evidence pack needs to be re-rendered in Mandarin and submitted to CATARC or another MIIT-designated body.
• Net effort for an OEM with mature R155 evidence: typically 3–6 months incremental work for the first vehicle type, dropping to 4–8 weeks for subsequent types once the bilingual evidence pipeline is in place.
• The largest practical risks are data residency (PIPL + CSL + DSL stacking on top of GB 44495), OTA infrastructure compliance, and dependency on China-domestic SBOM / vulnerability databases rather than NVD alone.

Quick comparison summary

Dimension	UNECE R155	GB 44495
Legal basis	UNECE 1958 Agreement; in EU adopted via Regulation 2019/2144	National standard (mandatory) under MIIT type approval; cross-references CSL, DSL, PIPL
Geographic scope	EU + UK + Japan + South Korea + 60+ UNECE 1958 contracting parties	People’s Republic of China (mainland)
Vehicle scope	Categories M, N, O with at least one ECU	M-class (passenger), N1 (light commercial); other categories phased
Effective date	New types 2022-07; all new vehicles 2024-07	Phased into MIIT type approval 2026–2028; verify against current MIIT 公告
CSMS requirement	Mandatory CSMS certificate, valid 3 years	Mandatory cybersecurity management process, audited as part of type approval (no separate certificate)
TARA requirement	Vehicle-specific TARA per Annex 5 threat list	Vehicle-specific risk assessment per GB 44495 §5 + Annex A threat catalog
Approving body	National type approval authority + designated technical service (KBA, RDW, etc.)	MIIT-designated body, primarily CATARC; entry on MIIT vehicle-product announcement catalog (车辆产品公告)
Threat catalog	R155 Annex 5 (~32 high-level threats across 7 attack categories, with associated vulnerabilities and mitigations)	GB 44495 Annex A (broadly aligned with R155 but reorganized; adds China-context threats e.g. domestic positioning systems)
SBOM	Not explicitly mandated; ISO/SAE 21434 recommends software identification	SBOM expected as part of evidence; format guidance leans on Chinese national standards under SAC/TC260
Incident reporting	Notification to type approval authority required, no fixed timeline	Reporting to MIIT and (for personal data incidents) to CAC; coordinated with PIPL/DSL incident windows (typically 24–72 hours)
Post-market obligations	Monitoring + updates throughout vehicle lifetime	Monitoring + updates + Chinese-resident vulnerability database registration; OTA infrastructure must comply with separate OTA standards
Language of evidence	Authority-dependent; English commonly accepted	Mandarin; bilingual technical files acceptable but the controlling version is Mandarin
Mutual recognition with R155	n/a	Not formally; partial reuse of evidence accepted at body discretion
Penalty for non-compliance	Withdrawal of type approval; vehicle cannot be sold in EU	Refusal of type approval; removal from MIIT vehicle-product announcement catalog; vehicle cannot be sold in China

What GB 44495 actually requires

GB 44495 (full title: “Technical requirements for vehicle cybersecurity”; in Mandarin “汽车信息安全通用技术要求”) is structured around three primary deliverables that an OEM must demonstrate to the assessing body:

1. A cybersecurity management process at the manufacturer level

The OEM must show that cybersecurity is governed by a documented process that covers concept, development, production, post-production monitoring, and end-of-support. The process must define roles, responsibilities, training, supplier management, and the change-control flow for cybersecurity-relevant decisions. This is functionally the same as R155’s CSMS.

Two practical differences from R155:

• GB 44495 does not issue a standalone “CSMS certificate”. Cybersecurity management is audited as part of the vehicle type approval, not as a separate organizational certificate with a 3-year validity.
• The auditing body expects evidence of local supplier governance — if your Tier-1 suppliers are EU-based, you must show how their cybersecurity activities are coordinated under your Chinese type approval, including any data-handover arrangements that touch PIPL or DSL.

2. A vehicle-type-specific risk assessment

For each vehicle type submitted for approval, the OEM must produce a TARA that:

• Identifies cybersecurity-relevant assets in the vehicle.
• Enumerates threat scenarios using the GB 44495 Annex A catalog as a baseline.
• Rates impact and feasibility, computes risk, and defines mitigations.
• Demonstrates that residual risk is acceptable for the intended use.

Annex A’s threat catalog is broadly aligned with R155 Annex 5 but reorganized into Chinese-language categories. A few categories carry context that is more strict or differently framed than R155: in particular, threats relating to domestic positioning and navigation systems (BeiDou), cellular V2X (C-V2X) rather than DSRC, and data-export pathways reflecting CSL/DSL constraints.

If your TARA is already structured to ISO/SAE 21434 Clause 15, the GB 44495 TARA is largely a remapping exercise rather than a reauthoring exercise. The threat IDs change, the language changes, but the analytical structure is the same.

3. Demonstrated controls and evidence pack

The OEM must show that risk-treatment decisions have been implemented and verified. Evidence is submitted to the assessing body in a Mandarin-language technical file that typically includes:

• Architecture documentation (E/E architecture, trust boundaries, key interfaces).
• Software inventory (SBOM) with mapping to known vulnerabilities.
• Vulnerability handling procedure including CNNVD/CNVD database integration.
• Security update mechanism documentation, demonstrating compliance with the automotive OTA standards referenced by GB 44495.
• Test reports for security controls (penetration tests, fuzz tests, integration tests).
• Incident response plan with specific MIIT/CAC reporting workflows.
• Records of internal audits and supplier assessments.

What stays the same vs. R155

If you have mature R155 evidence, you carry over more than you might fear.

Process documentation: ~80–90% reusable

Your CSMS policies, training records, internal audit procedures, supplier management framework, and incident response plan port over with translation. The auditing body looks for the same management-system properties; only a few sections need additions (PIPL/DSL touchpoints, local representative, domestic supplier governance).

TARA structure: ~70–80% reusable

Asset definitions, attack-feasibility scoring rubrics, threat enumeration logic, and risk-treatment decisions translate directly. The work is in remapping threat scenarios from R155 Annex 5 IDs to GB 44495 Annex A IDs, and in adding Chinese-context threats that R155 does not enumerate (e.g. specific BeiDou-spoofing scenarios, C-V2X-specific attacks, data-export routes affected by DSL).

If your TARA platform supports multi-standard catalog overlays, this is hours, not weeks. If your TARA is in Excel, plan for several engineer-weeks per vehicle type to do the remapping by hand.

Test evidence: ~60–70% reusable

Penetration tests, fuzz tests, and integration test reports are reusable in substance but typically need a new cover sheet, a Mandarin executive summary, and (in some cases) additional tests covering Chinese-specific protocols (BeiDou, C-V2X, GB-mandated cryptography algorithms such as SM2/SM3/SM4 where applicable to the vehicle type).

SBOM: ~95% reusable, formatting work

If your SBOM is in CycloneDX or SPDX, the underlying inventory is reusable. The Chinese assessing body increasingly expects vulnerability correlation to draw on CNNVD (China National Vulnerability Database, run by CNITSEC) and CNVD (China National Vulnerability Database, run by CNCERT/CC; its sub-database CNVD-ICS covers industrial-control systems specifically) in addition to NVD/MITRE. Re-running your CVE correlation against these databases is an automated step, not a manual rewrite.

What changes substantively

Five things require new work, not just translation.

1. Type-approval body and submission flow

R155 evidence is submitted to your home-market type approval authority (KBA in Germany, RDW in the Netherlands, etc.) which then issues approval valid across all contracting parties. GB 44495 evidence is submitted to a MIIT-designated body in China — in practice CATARC (China Automotive Technology and Research Center) handles most cybersecurity assessments — and approval is valid only in mainland China. There is no automatic cross-recognition of an EU certificate.

The administrative effort here is not the technical TARA — it is establishing the local representative relationship, the document-control workflow for Mandarin-controlled-source documents, and the secure-channel for evidence handover that complies with DSL data-export rules.

2. Data residency and PIPL/CSL/DSL stacking

This is the largest practical surprise for European OEMs. GB 44495 does not itself impose data-residency requirements, but it operates inside a regulatory stack where any cybersecurity activity that processes personal data, vehicle telematics, or operationally important data must comply with:

• PIPL (Personal Information Protection Law) for personal data — including driver, passenger, and connected-account information.
• CSL (Cybersecurity Law) for “Critical Information Infrastructure” classifications — some OEM cloud backends fall within scope.
• DSL (Data Security Law) for important data and core data classifications.

Practical effect: if your post-production monitoring sends telematics, attack indicators, or vehicle health data out of mainland China to your global SOC, you must show that the data flow has cleared a CAC (Cyberspace Administration of China) cross-border data security assessment, or fits within a permitted exception, or is anonymized to the point where it no longer counts as PIPL-regulated personal data.

This is not a new requirement created by GB 44495; it is the existing PIPL/CSL/DSL stack made operationally relevant by the cybersecurity activities GB 44495 mandates. Many OEMs discover this only when their CSMS evidence pack is rejected because the vulnerability-monitoring procedure routes data to a non-Chinese SOC without an approved transfer mechanism.

3. OTA infrastructure compliance

R155 references the related UNECE Regulation R156 for software update management; GB 44495 sits above a separate Chinese OTA regime, the operative document being MIIT’s 2022 OTA filing notice (工信厅装函 [2022] 95号), supported by recommended national standards in the GB/T series. The substantive controls required — signed updates, rollback protection, integrity verification, fail-safe behavior — are similar to R156. The procedural requirements (MIIT pre-filing of OTA campaigns, notification windows, evidence retention) are different. Verify the current GB/T reference numbers and the MIIT filing template before designing your OTA evidence pipeline; the standard set has been actively revised.

If your OTA architecture is compliant with R156, the technical controls port over. The notification + logging + evidence-retention layer needs a China-specific implementation: timing windows align with CSL incident-reporting expectations, and logs must be retrievable on MIIT request.

4. Vulnerability databases and disclosure workflow

R155 expects a vulnerability monitoring program but does not specify databases. Chinese assessors increasingly expect vendor monitoring to include CNNVD and CNVD alongside NVD/MITRE. These databases publish vulnerabilities that NVD does not, primarily for Chinese-developed components and locally distributed open-source forks.

The disclosure flow also differs. R155 leans on coordinated disclosure with the type approval authority. GB 44495 expects coordination with CNVD (or CNVD-ICS for industrial-control vulnerabilities specifically) and with MIIT for vehicle-population-affecting incidents, with overlapping personal-data reporting to CAC if PIPL applies. Building a cleanly orchestrated workflow that meets all three overlapping reporting windows takes thought; it is rarely a copy of the EU disclosure SOP.

5. Domestic supplier governance

If your Chinese vehicle type uses Chinese-domiciled Tier-1 or Tier-2 suppliers (typical for HMI, infotainment, certain ADAS subsystems, and increasingly battery management for EVs), the OEM must demonstrate that those suppliers are governed under the same cybersecurity management process. Supplier interface agreements typically need to be re-papered in Mandarin and aligned with the auditing body’s expectations.

The cleanest path here is to reuse the supplier-cybersecurity-questionnaire structure you already have for European Tier-1s, translate it, and add specific clauses covering DSL/PIPL touchpoints, localized vulnerability disclosure, and CNNVD subscription.

Practical OEM market-entry checklist

Use this checklist as a sanity check — not a substitute for engagement with a qualified local representative and your assessing body.

12 months before first Chinese type approval

1. Identify your local representative in mainland China and define the cybersecurity-decision interface.
2. Engage CATARC (or your designated assessing body) for a pre-application briefing — budget for 1–2 rounds.
3. Begin Mandarin technical translation of CSMS process documents (allow 2–3 months for a first pass, plus internal review).
4. Map your R155 Annex 5 threat catalog to GB 44495 Annex A and identify the China-context threats you need to add to your TARA template.
5. Review your data-flow architecture against PIPL/CSL/DSL. If your monitoring platform exfiltrates data from China, plan the cross-border transfer mechanism.

6 months before

1. Run a full TARA on your Chinese vehicle type using the GB 44495 catalog and have a Mandarin-fluent reviewer validate.
2. Stand up CNNVD/CNVD vulnerability monitoring alongside your existing NVD pipeline.
3. Validate your OTA infrastructure against the Chinese OTA standard stack — particularly logging, retention, and MIIT-accessibility.
4. Re-paper supplier interface agreements for Chinese Tier-1s.

3 months before

1. Final internal audit using GB 44495 + CSL/PIPL/DSL touchpoint criteria.
2. Compile the Mandarin evidence pack.
3. Run a tabletop incident-response drill covering the MIIT + CAC + CNVD reporting flows with realistic timing windows.
4. Submit pre-assessment package to CATARC for informal review.

Submission and post-approval

1. Submit formal type-approval cybersecurity package.
2. Respond to assessor questions (typical: 2–4 rounds).
3. Once approved, configure continuous monitoring against CNNVD/CNVD and integrate alerts into your CSMS.
4. Establish a quarterly reporting rhythm with MIIT for population-level vulnerability data; this varies by vehicle type and is set during approval.

Common pitfalls

Treating GB 44495 as “R155 in Chinese”

The standards are aligned, not equivalent. Reusing your EU evidence verbatim — without remapping the threat catalog, without adding domestic-supplier clauses, without validating data flows against PIPL/CSL/DSL — reliably leads to assessor pushback or outright rejection. The lift is real even if it’s incremental.

Underestimating the data-flow review

Many OEMs discover late in the cycle that their global SOC, threat intelligence platform, or telemetry backend is non-compliant from a CSL or DSL perspective. Re-architecting telemetry routing inside an active type approval is expensive. Audit data flows during the 12-month-prior phase.

Not using a Mandarin-fluent reviewer for the TARA

Annex A threat IDs are not just translations of R155 Annex 5 IDs. The subtle reorganization of categories means that an English-only reviewer can produce a TARA that “looks complete” in IDs but missed Chinese-context scenarios that the assessor will ask about. Have a Mandarin-fluent reviewer validate before submission.

Forgetting the OTA logging discipline

R156-compliant OTA architectures often forget the MIIT-accessible logging layer until the assessor asks for it. Plan for log retention, indexable by VIN and software version, with a documented procedure for MIIT queries.

How this maps to ISO/SAE 21434 and a single-source TARA

Both R155 and GB 44495 reference, or are aligned with, ISO/SAE 21434. If your TARA workflow is structured to ISO/SAE 21434 Clauses 9 (concept), 10 (product development), and 15 (TARA), you can run a single-source TARA whose output is rendered into both R155 Annex 5 mappings and GB 44495 Annex A mappings.

The platform-level pattern for this is:

1. Author the TARA against ISO/SAE 21434 in your tooling.
2. Maintain a catalog overlay mapping that converts ISO 21434 threat scenarios to R155 Annex 5 and GB 44495 Annex A IDs.
3. Generate the regional evidence pack (R155 vs GB 44495) from the same source TARA via templates.
4. Track the delta between catalog versions over time so that when GB 44495 is revised (expected biennially), only the delta needs revisiting.

This is what an automated TARA platform does for you when it ships with multi-standard catalog overlays. Done by hand, the remapping discipline is feasible but easily becomes a source of inconsistency between what an OEM submits to KBA and what it submits to CATARC.

Key takeaways

1. GB 44495 is being phased into MIIT vehicle type approval; the operative dates are set by MIIT 公告, not the standard text — verify the latest announcement before each submission. There is no mutual recognition with R155.
2. If you have mature R155 + ISO/SAE 21434 evidence, you reuse roughly 70–90% of CSMS process docs and TARA structure. The lift is in remapping the threat catalog, translating to Mandarin, and adding Chinese-context elements.
3. The largest practical risks are data residency (PIPL/CSL/DSL stacking on top of GB 44495), OTA logging compliance, and vulnerability database coverage (CNNVD/CNVD alongside NVD).
4. Plan for a 12-month runway for first-vehicle-type Chinese type approval, dropping to 4–8 weeks per subsequent vehicle type once the bilingual evidence pipeline is in place.
5. Engage CATARC (or your designated assessing body) early, secure a local representative, and build a Mandarin-fluent technical review capability before submission. Don’t submit cold.

Further reading

• GB 44495 Vehicle Cybersecurity Standard — landing page
• UNECE R155 Type Approval Guide
• ISO/SAE 21434 TARA Step-by-Step Guide
• EU CRA vs UNECE R155
• CSMS Audit Preparation Checklist
• Post-Production Cybersecurity Monitoring