Chinese OEMs, ODMs, and brand owners taking connected products into EU, US, UK, and other export markets carry a security posture built for the domestic regulatory frame — and discover, often late in the certification cycle, that the same posture does not satisfy foreign regulators. The technical work is rarely the gap. The gap is in what the engineering team has been asked to document, what the disclosure policy looks like to an outside researcher, and what obligations the product carries after it leaves the warehouse.
We work with Chinese manufacturers across this transition: pre-export readiness assessment, gap remediation against the target-market regulatory frame, and bilingual reporting that lets the China-based engineering team and the export-market compliance contact work from the same document.
What changes when you cross a regulatory border
The China-domestic posture is anchored on MLPS 2.0 (Multi-Level Protection Scheme), with adjacent obligations from PIPL, DSL, and — for products classified as Critical Information Infrastructure — the CII regime. MLPS is operator-centric: the obligation sits with the system operator within China, the grading process is structured around graded assessment by licensed assessors, and the evidence package is built for that assessor and for the regulator.
Export markets shift this in three ways:
- The obligation moves from operator to manufacturer. EU CRA, UK PSTI, and US Cyber Trust Mark are product-level frames that bind the manufacturer for the lifetime of the product on that market — not the operator running the system after delivery.
- The evidence package changes audience. MLPS evidence is built for a Chinese assessor and a Chinese regulator. CRA evidence is built for an EU notified body, a market-surveillance authority, and — in practice — external security researchers reading the manufacturer’s vulnerability disclosure policy.
- Post-market obligations expand. CRA’s five-year support window (or the product lifecycle, whichever is shorter), PSTI’s defined-support-period statement, and Cyber Trust Mark’s annual renewal each impose a post-market security obligation that is not the default MLPS frame.
Where MLPS posture most often leaves a gap is in product-level documentation that survives outside the operator context — Software Bill of Materials (SBOM), coordinated vulnerability disclosure (CVD) policy, secure-update infrastructure with a documented anti-rollback story, and the long-tail post-market support commitment.
Regulatory comparison: China → EU → US
| Dimension | China-domestic | EU export | US export |
|---|---|---|---|
| Primary product-security frame | MLPS 2.0 (operator-centric) | EU Cyber Resilience Act (manufacturer-centric, in force from late 2027) | US Cyber Trust Mark (voluntary, FCC-administered) + sector-specific FCC equipment authorization |
| Personal data frame | PIPL — consent + cross-border transfer rules | GDPR — lawful basis + data subject rights | Sectoral (CCPA, HIPAA, COPPA) — no general federal regime |
| Vulnerability disclosure | CNNVD / CNVD coordination; no explicit manufacturer-CVD mandate at product level | CRA Article 11: mandatory CVD policy + 24-hour active-exploitation reporting to ENISA | Cyber Trust Mark conformance: documented CVD policy; CISA coordination expected |
| SBOM expectation | Encouraged for graded systems, not product-level mandate | CRA Annex I: SBOM as essential cybersecurity requirement | Cyber Trust Mark: SBOM required for the program |
| Secure update | MLPS graded-system control; OTA infrastructure assessed at operator level | CRA: manufacturer obligation across the product’s support period | Cyber Trust Mark + FCC: manufacturer obligation |
| Support period commitment | Tied to the operator’s system lifecycle | CRA: minimum 5 years or product lifetime, whichever shorter | Cyber Trust Mark: annual renewal; clear support-end statement |
Where MLPS overlaps: the technical controls — secure boot, encrypted communication, authentication strength, access control — translate cleanly across regimes. Where it does not: documentation audience, post-market obligation, and the bilateral disclosure conversation with external researchers.
PIPL and GDPR overlap on the consent foundation and on data subject rights, and they diverge sharply on cross-border transfer: PIPL requires CAC security assessment, standard contract filing, or certification for outbound personal information, with thresholds defined in the 2024 Provisions. GDPR’s Chapter V framework (adequacy decisions, SCCs, BCRs) does not map symmetrically. For a Chinese manufacturer shipping a connected product to EU households, both regimes apply at once — the device collects EU personal data under GDPR, and the back-end processing of that data, if it routes through China-hosted infrastructure, is also an outbound transfer under PIPL.
Common readiness gaps we see
The gaps that surface in pre-export assessment are remarkably consistent across product classes:
- SBOM coverage is partial. The team often has a third-party-component inventory for procurement reasons but has not extended it to first-party modules, has not bound it to the build pipeline, and has not produced it in a format (CycloneDX, SPDX) that a notified body will accept.
- Vulnerability disclosure policy is absent or domestic-only. The product carries a Chinese-language disclosure email at best — often nothing at all. CRA Article 11 expects a documented policy, a stated coordination window, and a path for external researchers to reach the manufacturer in a working European language.
- Secure-update infrastructure assumes operator-side control. OTA signing keys, anti-rollback enforcement, and update-failure recovery paths are designed assuming the operator (often the manufacturer’s own China-domestic ops team) controls the update server. Export markets require the same controls to function with distributed operators, regional CDNs, or — in the consumer case — direct device-to-cloud update without an intermediate operator.
- Post-market support is undeclared. The product ships with no public statement of how long security updates will be provided. PSTI in the UK and CRA in the EU both require an explicit declared support period.
- Hardware attack surface documentation is sparse. Debug-interface state, secure-boot chain configuration, and fault-injection resistance are often known to the engineering team but not documented in a way that supports the CRA’s risk-assessment Annex I obligations.
Each of these gaps is recoverable in a pre-export remediation cycle, provided it is identified before the certification submission window closes.
Bilingual remediation guidance
The engineering team that built the product typically works in Chinese. The compliance contact who will submit to the EU notified body or coordinate with the FCC test lab often works in English. The vulnerability disclosure policy, the SBOM package, the post-market support statement, and the user-facing security documentation all need to land cleanly in both languages.
Our remediation reports are bilingual by default: every finding, every recommendation, and every traceability artifact appears in EN + ZH side by side. The China-based firmware engineer and the export-market compliance lead work from the same document, with no translation drift between them and no ambiguity at the handoff. For findings that require regulatory framing in the target market, the English narrative carries the regulatory citation; for findings that touch China-domestic obligations (where MLPS or PIPL remediation may also be needed for the home-market posture), the Chinese narrative carries the corresponding citation.
This is not translation as an afterthought. The bilingual reporting model is part of the engagement structure: lead consultant briefs are run bilingually, exit presentations are run bilingually, and the post-engagement Q&A channel stays open in whichever language the engineering team uses.
Engagement shape
For Chinese manufacturers in pre-export readiness, the Scoped Assessment model fits best. Scope is real (a defined product, a defined target market, a defined certification frame) but the gap surface is unknown until the initial review — which makes a fully Fixed Package quote unfair to either side. The assessment defines the gap, sizes the remediation, and (where the manufacturer wants continuous coverage across a product roadmap) converts into a Retainer for the next product cycle.
For manufacturers operating multiple product lines into multiple target markets — say, a consumer-IoT brand shipping into EU under CRA, into UK under PSTI, into US under Cyber Trust Mark, and maintaining MLPS posture for the China-domestic version — a Custom Engagement framing covers the cross-product, cross-market coordination work that a single Scoped Assessment cannot.
Service mapping
Chinese manufacturers exporting connected products typically work with us across:
- IoT & Embedded Security — for the firmware, hardware, and protocol layers
- Automotive Cybersecurity — for vehicle and ECU-class products entering UN-R 155 / ISO/SAE 21434 type-approval markets
- ISO/SAE 21434 Readiness — for the CSMS process layer
- ISO 27001 & SOC 2 Readiness — for the organizational and operational layer that export buyers increasingly require alongside product-level conformance
What buyers ask us first
Three questions surface in roughly every initial conversation with a Chinese manufacturer in pre-export readiness:
“Do we need to re-do the security work we already did for MLPS?” Mostly no — the technical controls translate. What you need to do is repackage the existing evidence for a different audience (notified body, market-surveillance authority, external researcher) and extend the post-market commitment structure. The substantive technical posture is usually closer to compliant than the team expects; the documentation surface is where the gap lives.
“How long does pre-export remediation take?” For a single product line with a defined target market, 8-14 weeks from assessment kickoff to certification-ready evidence package. Multi-market scope (EU + UK + US simultaneously) adds coordination overhead but not proportionally more substantive work — the underlying technical posture is the same across regimes; only the documentation framing differs.
“Do you also handle the China-domestic side after we go international?” Yes. Many of our Chinese-manufacturer clients run a parallel posture — domestic MLPS maintenance plus export-market product-level obligations — and the two are easier to maintain coherently than separately. The mapping in the regulatory comparison table above is the practical foundation for that coherent maintenance.
“The manufacturer who built a strong MLPS posture has done 70% of the work needed for CRA conformance. The remaining 30% is the post-market documentation, the disclosure policy, and the SBOM packaging — none of which is technically hard, but all of which has to be in place before certification submission.” — Tatiana K., CEO, Melina Security
Frequently asked questions
Is the EU Cyber Resilience Act actually in force, or is the deadline still moving?
CRA was published in the Official Journal in late 2024 and enters substantive application in late 2027 (with reporting obligations under Article 11 entering earlier, in September 2026). Manufacturers shipping into the EU after the substantive application date must comply across the full essential cybersecurity requirements in Annex I. Pre-2027 launches are not retroactively scoped, but post-2027 maintenance of products already on market is.
Do we need a separate engagement for each target market or can we do EU + UK + US in one?
One engagement covers multi-market scope efficiently because the underlying technical posture is shared. The bilingual remediation report is generated once; the regulatory framing for each target market layers onto the same technical findings. The coordination overhead is in stakeholder alignment, not in duplicate technical work.
How do we handle vulnerability disclosure across regulatory boundaries?
A single coordinated vulnerability disclosure (CVD) policy with explicit multi-jurisdictional language is the practical answer. CRA Article 11 requires the policy be discoverable and operational; PSTI requires defined contact paths; Cyber Trust Mark requires CISA coordination compatibility. The same policy document satisfies all three with the right framing. Where China-domestic CNNVD coordination is also relevant, we handle that as a sibling track within the same policy.
What if our product is too far along to do a meaningful pre-export assessment?
Late-stage assessment is still valuable — the cost-curve of finding issues pre-certification vs post-certification vs post-recall is sharply non-linear (see the pre-launch secure-boot case study for the dynamics). The question is whether the schedule allows remediation. If your certification submission is more than 8 weeks out, useful remediation is possible. Less than 4 weeks, scope contracts to documentation gaps only.
Do you work with sub-component manufacturers (chipset, module, RTOS) or only with brand owners?
Both. Sub-component manufacturers ship security guidance to their integration customers; brand owners integrate sub-component guidance into their finished-product posture. The cleanest engagements happen when both parties are aligned on what’s the sub-component’s responsibility vs the brand owner’s — which is itself a frequent gap our assessments surface.
Related
- China Compliance — pillar — for the MLPS, PIPL, DSL, and CII baseline
- IoT Firmware Secure-Boot Bypass — case study — anonymized example of a finding that surfaces in pre-export hardware review
- IoT Supply-Chain Vulnerabilities — Procurement Responsiveness Profile — companion framework for the supply-chain transparency expectations under CRA and Cyber Trust Mark
- Industries — pillar
- Engagement models