← Back to: Battery Charging / Gauging / Protection / BMS
Introduction & Problem Statement
In a BMS-centered charging architecture, no accessory or battery pack should be permitted to enable full-current or fast-charge profiles before its identity is authenticated. This page belongs to the charging branch, so authentication here is a charging gate, not a generic IoT security add-on.
We need to block three high-impact patterns right at the charging entry: fake or re-labeled batteries with no real JEITA/NTC capability, non-approved or cloned adapters that do not match your modeled voltage/current profiles, and unauthorized accessories that would pollute cloud billing, warranty, and usage tracking. All three can look electrically compatible, but all three will mislead the charger MCU and the gauge if we do not authenticate them first.
This is why authentication must happen before the charger enables fast charge, before the power-path puts the system first, and before telemetry is sent to the cloud-side mapper for fleet or billing decisions.
Why not every battery can be charged
The charger must know if the pack truly supports JEITA/NTC and the target charge profile. If the identity is not signed, the system must stay in a degraded or safe-current mode.
Why we write this into the BOM
Small-batch purchasing tends to swap in “function-compatible” parts without authentication payloads. A BOM remark makes this impossible and protects the charging path.
Why cloud-side normalization is mandatory
TI, ST, NXP, Renesas, onsemi, Microchip, and Melexis do not report the same auth fields. The cloud mapper must normalize them before analytics and cross-brand alternatives.
BOM-ready statements:
• Charging path must verify battery or adapter certificate before enabling fast-charge or high-power profiles.
• Batteries that do not expose JEITA/NTC capability in their authentication payload must be treated as degraded accessories.
• Cloud-side telemetry mapping must be updated before using cross-brand batteries or adapters.
Threat & Risk Model for Charging Accessories
We focus only on threats that alter the charging curve, the thermal behavior, or the cloud-side record. The danger is not just “fake parts”; the real danger is that the charger MCU, gauge, or cloud believes an unsafe or unverified accessory is safe and enables fast charge for it.
Entry points are not limited to the battery. Adapters, docks, cradles, and smart power cables can also bypass policies if they do not present a signed identity. This is why every unauthenticated entry must be degraded and logged for purchasing and service teams.
Non-JEITA / wrong NTC battery
Charger believes it can derate by temperature, but the pack cannot. Result: overheated port or repeated protection.
BOM: “Non-JEITA batteries must be treated as degraded accessories even if voltage range is compatible.”
Non-approved adapter
Adapter claims a power profile that does not match the device model, forcing the charger IC into protection or fallback.
BOM: “Adapters that do not return signed identity must not unlock high-power PDO.”
Re-badged / cloned battery
One ID appears in many places; cloud billing and warranty data are polluted and cannot be audited.
BOM: “Batteries with non-unique or unverifiable IDs must not be approved for fleet use.”
Cross-fleet misuse
A battery from device A is charged on device B with a different safety strategy. Without binding, BMS cannot apply the right limits.
BOM: “Authentication payload must contain fleet or model binding; accessories without binding must be charged in degraded mode only.”
BOM-ready statements:
• Non-JEITA batteries must be treated as degraded accessories even if voltage range is compatible.
• Adapters that do not return signed identity must not unlock high-power PDO.
• Batteries with non-unique or unverifiable IDs must not be approved for fleet use.
• Authentication payload must contain fleet or model binding; accessories without binding must be charged in degraded mode only.
System Placement: Where the Authenticator Lives
Placement matters because the charging state machine must have a signed identity before it decides to (1) move from pre-charge to fast charge, or (2) allow a VSYS ↔ VBAT power-path handover. We only allow three canonical topologies to avoid cross-page overlap.
We do not go deep into USB-PD policy, vehicle-port authorization, or generic IoT security flows here. This chapter only states: the charging MCU must have a verified identity before granting high-current charging.
In-pack SE
Battery itself carries the secure element. Charger/host reads it over I²C/1-wire right after pack attach.
Affects: pre-charge → fast charge gate. Best for packs that can report real JEITA/NTC.
In-adapter SE
Adapter or dock exposes an ID. Device authenticates power source first, then enables charging.
Affects: VSYS ↔ VBAT power-path and source-power unlocking. Firmware/cert can be updated per adapter.
In-host SE (multi-accessory)
Host has a trusted SE; every battery or adapter must pass through it. Best when a single device sees many accessories.
Affects: new session start and accessory change. Cloud needs to read host logs only.
BOM-ready statements:
• Auth must complete locally before the charging state machine moves from pre-charge to fast charge or enables VSYS ↔ VBAT power-path.
• Do not approve cloud-only authentication for real-time charging decisions.
• Choose in-pack / in-adapter / in-host topology based on which accessory class changes most frequently.
Auth Payload, Certificates, and Cloud Binding
This is the data heart of the page. Every cross-brand mapping, every purchasing restriction, and every “7-brand-only” rule depends on how complete and how verifiable this authentication payload is.
The charger MCU must receive a signed, structured payload — not an arbitrary string — so that purchasing can say: “Accessories without signed capability fields are low-grade and must not be used as cross-brand equivalents.”
Signed Device ID
Globally unique ID, signed by vendor. Used to block re-badged/cloned accessories.
Manufacturer / Brand Code
Must map to TI, ST, NXP, Renesas, onsemi, Microchip, or Melexis. Others → degraded.
Model / Variant / Batch
Used to attach the right JEITA table and temperature profile in the cloud mapper.
Charging Capability Flags
fast-charge-capable, power-path-capable, JEITA/NTC-present. Missing → treat as degraded.
Warranty / Billing Hooks
Optional but important for fleet: rental ID, warranty term, authorized channel.
BOM-ready statements:
• Do not approve battery packs or adapters that do not expose signed capability flags (fast charge, power-path, JEITA/NTC).
• Cloud-side telemetry mapping must be updated before using cross-brand batteries or adapters beyond TI, ST, NXP, Renesas, onsemi, Microchip, and Melexis.
• Charger MCU must verify signatures locally; private keys must not be stored in the charger MCU.
Interaction with Charger, Gauge, and Power-Path
Charging decisions must be made after the accessory / battery ECID is authenticated. The authentication result becomes an input to the charging state machine and decides whether we run a normal CC/CV sequence, a degraded trickle-like charge, or a full refusal with logging.
Charging path must not enable full-current or fast-charge profiles before accessory/battery ECID is authenticated. This line must stay in the BOM and purchasing notes.
Auth OK → normal charge
pre-charge → CC/CV → recharge. Gauge tags cycle as authenticated. Power-path can promote battery to normal priority.
USB-C Sink may advertise high-power PDO when adapter is also authenticated.
Auth FAIL → degraded
Stay in low-current or trickle. Do not allow VSYS ↔ VBAT high-current switching. Gauge records “unauth accessory”.
Cloud log should mark this session as “limited by auth”.
Auth MISSING / TIMEOUT → refuse / log
Either refuse charging or give the minimal safe current only. Force an upload to the cloud / gateway.
For USB-C coordination: only advertise low-power PDO.
BOM-ready statements:
• Charging path must not enable full-current or fast-charge profiles before accessory/battery ECID is authenticated.
• Gauge must differentiate “battery fault” from “unauth accessory”; both must be reportable to cloud.
• When auth_result != OK, power-path must stay in system-priority or low-power mode, and USB-C must only advertise low-power PDO.
Cross-Brand Payload Normalization (TI / ST / NXP / Renesas / onsemi / Microchip / Melexis)
You can only swap within TI / ST / NXP / Renesas / onsemi / Microchip / Melexis. If you want to bring in another brand, update the telemetry mapper first. The reason is simple: the cloud must know the field names, capability flags, and signature style before it can tell the charger MCU “this accessory can be treated as normal charge”.
Some vendors put JEITA or temperature capability directly in the auth payload (NXP SE050, Microchip ATECC608C with custom slots), others return only an ID (TI BQ26100 / BQ26150), and some expose data via a different diagnostic path (onsemi LC709204F/LC709209F). Without normalization, they cannot be used interchangeably.
TI
BQ26100, BQ26150
Short, battery/accessory auth; JEITA usually elsewhere → need mapping.
ST
STSAFE-A100, STSAFE-L010
Structured payload; can hold brand + lifecycle + channel.
NXP
EdgeLock SE050, A5000
I²C secure element, cloud-friendly, often already has device model.
Renesas
ISL6296A, ISL9206A
FlexiHash style; must be unpacked → then mapped.
onsemi
LC709204F, LC709209F
Fuel-gauge centric; treat as “unsigned telemetry” → degraded until mapper updated.
Microchip
ATECC608C, ATSHA204A, TA100
ECC/PKI style; best for accessories that must carry cert chains.
Melexis
MLX81115, MLX81118, MLX81112
LIN slave class → identifiable but unsigned → map as soft-ID.
BOM-ready statements:
• You can only swap within TI / ST / NXP / Renesas / onsemi / Microchip / Melexis. If you want to bring in another brand, update the telemetry mapper first.
• Mapper not updated ≠ accessory cannot be used, but it must be treated as a downgraded accessory and must not unlock fast-charge or high-power PDO.
• Charger MCU and front-end must share the same auth_result dictionary; unknown codes must show as “unauth / degraded”.
BOM Remarks & Small-Batch Procurement Hooks
This block centralizes the mandatory BOM notes for authenticated charging accessories. Paste these into your BOM “Notes” or purchasing description to prevent small-batch substitutions with non-authenticated packs.
Auth gating
“Charging path must verify battery or adapter certificate before enabling fast-charge profile.”
“If authenticator is absent or invalid, charger must fall back to pre-charge / low-current mode.”
Brand restriction
“Approved alternatives must come from TI / ST / NXP / Renesas / onsemi / Microchip / Melexis only.”
“Purchasing must not introduce non-listed brands without updating the cloud-side telemetry mapper.”
Cloud sync / mapper
“Cloud-side telemetry mapping must be updated before using cross-brand batteries/adapters.”
“If mapper does not support this vendor, treat the accessory as degraded and keep system-priority power-path.”
JEITA / NTC safety
“Batteries or adapters without JEITA/NTC-binding data must be treated as degraded accessories.”
“Non-JEITA batteries must not unlock high-current or VSYS↔VBAT transitions even if voltage is compatible.”
Reporting / traceability
“Authentication result must be logged and uplinked for billing and warranty decisions.”
“Gauge must distinguish ‘unauth accessory’ from ‘battery failure’ in upload records.”
Small-batch guard
“Do not approve accessories that expose capacity/voltage only without signed capability flags.”
Copy/paste BOM (minimal):
• Charging path must verify battery or adapter certificate before enabling fast-charge profile.
• If authenticator is absent or invalid, charger must fall back to pre-charge / low-current mode.
• Approved alternatives must come from TI / ST / NXP / Renesas / onsemi / Microchip / Melexis only.
• Cloud-side telemetry mapping must be updated before using cross-brand batteries/adapters.
• Batteries or adapters without JEITA/NTC-binding data must be treated as degraded accessories.
• Authentication result must be logged and uplinked for billing and warranty decisions.
Test & Validation for Anti-Counterfeit in Charging
Validation must confirm not only “charging works”, but also “charging does not proceed or is downgraded when authentication fails, times out, or is not mapped in the cloud.” Each scenario below must produce both a safe charging behavior and an explicit log.
Power-on → auth → charge
Expected charge: pre → CC/CV → recharge.
Expected log: auth_result=OK, auth_source=battery/adapter, charger_action=normal.
Adapter change mid-charge
Expected charge: re-auth; if unauth → degraded.
Expected log: event=adapter_swap, auth_result=FAIL|MISSING, charger_action=degraded.
Battery swap (same brand)
Expected charge: normal, but log new cert.
Expected log: auth_cert_version=…, charger_action=normal.
Battery swap (cross-brand 7厂)
Expected charge: normal if mapper has both; else degraded.
Expected log: brand_before=TI, brand_after=ST, cloud_mapper=KNOWN|UNKNOWN.
Auth fail / timeout
Expected charge: refuse or minimal current; low-power PDO.
Expected log: auth_result=TIMEOUT|INVALID_SIG, charger_action=refused.
Cloud mapper not updated
Expected charge: local OK → degraded until cloud update.
Expected log: auth_result=OK_LOCAL, cloud_mapper=UNKNOWN_VENDOR, charger_action=degraded.
Test checklist (copy):
• Validate with authenticated battery and authenticated adapter at room / low / high temperature.
• Validate mid-charge accessory swap → state machine must re-run auth.
• Validate cloud-offline mode → local auth must still produce degraded-safe behavior.
• Validate tampered / re-badged adapter → immediate degrade + upload.
Request a Quote
Frequently Asked Questions
All questions on this page stay within the charging authentication branch — identity → charging profile → logging → seven-brand procurement. We do not answer HV insulation, pack-FET, or vehicle-level OTA topics here.
1) Why can’t I enable fast charge for every battery or adapter I plug in?
Because in a BMS-centered charging architecture, fast charge is an authorized state, not a generic voltage-compatible state. The charger must first verify that the battery or adapter presents a valid, signed identity and that it declares JEITA/NTC capability. If the accessory is unknown, cloned, or not mapped, the charger must stay in pre-charge or low-current mode.
2) Where does the authenticator sit in this architecture — battery, adapter, or host?
It can live in the battery pack (in-pack SE), in the adapter (in-adapter SE), or in the host (for multi-accessory devices). No matter the placement, authentication must complete before the charger enables the full-current or fast-charge profile. This FAQ only covers charging-time authentication, not general IoT security or vehicle gateways.
3) What happens if the authenticator IC is missing or the certificate is expired?
The charger must fall back to the safest charging mode available: pre-charge, trickle, or even refuse with logging. This is the BOM line you should keep: “If authenticator is absent or invalid, charger must fall back to pre-charge / low-current mode.” The event must also be reported to the cloud or edge gateway for fleet and warranty decisions.
4) How does the authentication result map to the charging state machine?
Typically: Auth = OK → pre-charge → CC/CV → recharge; Auth = FAIL → low/trickle only, no VSYS↔VBAT high-current switching; Auth = MISSING/TIMEOUT → refuse or minimal current plus forced log. This mapping is what keeps non-authenticated accessories from heating the port or corrupting cloud billing.
5) Can an unauthenticated adapter still power the system but not charge the battery?
Yes. The charger or USB-C sink can present only low-power PDOs or stay in system-priority power-path so the device runs, but it must not enable battery fast charge. This prevents fake or re-badged adapters from pushing unknown current into the pack while still allowing the user to keep the system on.
6) Why do non-JEITA batteries have to be treated as degraded even when the voltage matches?
Because without JEITA/NTC-binding data the charger cannot confirm safe thermal derating. In that case the only safe decision is to keep the accessory in degraded mode: low current, no fast-charge profile, and no VSYS↔VBAT high-current transitions, even though the nominal voltage looks compatible.
7) What must be logged to the cloud when an accessory fails authentication?
At minimum log: auth_result_code, auth_source (battery|adapter), brand_code (TI / ST / NXP / Renesas / onsemi / Microchip / Melexis), charger_action (normal | degraded | refused), and cloud_mapper_version. This is the set the purchasing team will check when they suspect small-batch parts were used.
8) What if the cloud telemetry mapper does not yet support this brand or device PN?
Then the accessory must be used as a degraded accessory even if local authentication was OK. The BOM note should say: “Cloud-side telemetry mapping must be updated before using cross-brand batteries/adapters.” Until that update happens, do not unlock high-power PDO or fast-charge profiles.
9) Do we have to re-authenticate when the adapter or battery is swapped during charging?
Yes. Any accessory swap is a potential identity change. The charger must re-run authentication and, if the new accessory fails or is unknown, immediately downgrade the charging current and log the event. Skipping this step is how fake adapters silently enter the charging fleet.
10) Why is the BOM restricted to TI / ST / NXP / Renesas / onsemi / Microchip / Melexis only?
Because these seven vendors have predictable authentication payloads and can be normalized by the cloud mapper. Bringing in a new brand without mapper support usually means the charger cannot tell if JEITA/NTC is available, so it must stay in degraded mode. The restriction protects small-batch purchasing from “looks compatible but not authenticated” parts.
11) Can purchasing approve a functionally compatible battery with no signed payload to meet lead time?
It can be approved, but only as a degraded accessory. It must not unlock fast-charge, must not enable VSYS↔VBAT high-current switching, and must be clearly labeled in the BOM notes as “unauth / cloud-mapper update required.” This is exactly the mistake small-batch teams make when they only look at voltage and connector.
12) How should I write BOM notes so that small-batch substitutions don’t bypass authentication?
Use hard, explicit English lines, for example: “Charging path must verify battery or adapter certificate before enabling fast-charge profile.” “Approved alternatives must come from TI / ST / NXP / Renesas / onsemi / Microchip / Melexis only.” “Cloud-side telemetry mapping must be updated before using cross-brand batteries/adapters.” These lines stop procurement from buying non-authenticated packs just to fix lead time.
