123 Main Street, New York, NY 10001

← Back to: eFuse / Hot-Swap / OR-ing Protection

Why Security for Power Paths?

Power paths (eFuse, Hot-Swap, Ideal-Diode/OR-ing) face practical risks: fake adapters or forged batteries, tampered EN/ILIM/PG/FAULT, and field bypasses that leave no evidence. The stack needs three layers: adapter/battery authentication, signed switching, and tamper-proof logs.

  • Pre-attach authentication: after a challenge–response, decide allow / limit / deny enable.
  • Signed switching: non-repudiable events for EN/ILIM changes, priority switches, and reverse-current blocking.
  • Tamper-proof logs: power-loss resilient, append-only, hash/MAC chained for RMA and compliance.

Anti-overlap: this page does not cover eFuse SOA, Hot-Swap loop compensation, or Ideal-Diode current-sharing math. It focuses on how security binds to (EN, ILIM, PG, FAULT, PRIORITY, ΔVtrip).

FRAC ↑ — higher fake-attach rejection
MTTR ↓ — faster fault localization
NFF ↓ — fewer “No-Fault-Found” returns
Event coverage ≥ 99%
{
  "AuthResult": {"adapter_id":"","battery_id":"","chal":"","resp":"","alg":"","key_slot":"","exp":"","ok":true},
  "EventRecord": {"counter":0,"ts":"UTC","action":"","path_id":"","ilim":0.0,"vdrop":0.0,"temp":0.0,"reason":"","mac":""}
}
Threat surfaces around eFuse / Hot-Swap / OR-ing Fake adapter, forged battery, EN/ILIM tamper, and log wipe around a Power Path; three mitigations. Power Path eFuse · Hot-Swap · Ideal-Diode / OR-ing EN / ILIM / PG / FAULT / PRIORITY / ΔV_trip Fake Adapter Overheat / Wrong ILIM Forged Battery Unsafe enable / Mis-charge EN / ILIM Tamper False OK / Hidden stress Log Wipe No evidence / High NFF Auth gates EN (allow / limit / deny) All switching events are digitally signed Logs are tamper-evident for RMA

Threat Model for eFuse/Hot-Swap/OR-ing

Decompose threats into four layers and bind them to concrete power-path signals with testable mitigations.

Physical/Electrical layer

  • Fake adapter, forged battery, hot-plug fishing, reverse current, rising contact resistance → priority flapping.
  • Interfaces: EN, ILIM, RCB, ΔVtrip, PRIORITY, PG.
  • Mitigations: pre-attach authentication; signed RCB triggers; ΔVtrip hysteresis + signed events.

Protocol/Control layer

  • EN/ILIM tamper, forged PG/FAULT, malicious TIMER; replay of a past success.
  • Interfaces: EN, ILIM, PG, FAULT, TIMER.
  • Mitigations: challenge–response; signed switching; replay windows and monotonic counters.

Maintenance/Process layer

  • Log wipe, serial reuse, weak key lifecycle.
  • Interfaces: log I/O, key-injection.
  • Mitigations: hash-chained logs, RBAC, revocation.

Environment/Boundary (optional)

  • Temperature cycling, brownouts, surge, noise → RNG quality and counter sync issues.
  • Mitigations: entropy checks; cold-start counter policy; power-up index; minimal surge record.
Fake AdapterAuthResult.ok=false → limit/deny + log reason=AuthFail
EN Tamper → verify signed token; on fail, revert and log
Log Wipe → chain break on boot → mark evidence contamination
Priority Flapping → add hysteresis; record ΔVtrip + direction
Threats mapped to mitigations for power-path interfaces Four threat families mapped to EN/ILIM/PG/FAULT/PRIORITY/RCB with mitigation tags. Threat → Mitigation Mapping Physical / Electrical Interfaces: EN, ILIM, RCB, ΔV_trip, PRIORITY, PG Mitigations: Auth gate, signed RCB, hysteresis Protocol / Control Interfaces: EN, ILIM, PG, FAULT, TIMER Mitigations: challenge–response, counters Maintenance / Process Interfaces: log I/O, key-injection Mitigations: hash-chained logs, RBAC Environment / Boundary Interfaces: RNG/RTC quality, counters Mitigations: entropy checks, surge record

Adapter & Battery Authentication Options

Authentication decides whether the power path is allowed, limited, or denied. ID storage ≠ authentication — use cryptographic proof with fresh nonces and monotonic counters to block replay.

Mechanism comparison

  • Symmetric (HMAC/CMAC): low cost/latency; needs nonce + counter and protected key distribution.
  • Asymmetric (ECDSA/EdDSA): non-repudiation & per-unit certs; higher latency/cost; quality RNG.
  • Physical interfaces: I²C, 1-Wire/HDQ, vendor sidebands (hot-plug/EMI rules apply).

Minimal data objects

{
  "AuthResult": {
    "adapter_id": "", "battery_id": "",
    "chal": "", "resp": "", "alg": "HMAC|ECDSA",
    "key_slot": 0, "exp": "UTC-ISO", "ok": true
  }
}
      

Brand attachment points

  • Microchip: ATECC on adapter/pack side.
  • NXP: SE050/EdgeLock via I²C; cloud mapping friendly.
  • ST: STSAFE/TPM lines; clean hook to power-domain gating.
  • TI: Gauge/charger/USB-PD with PG/EN gating.
  • Renesas: RA MCU + SCE bridge.
  • onsemi: Power/monitor with external SE.
  • Melexis: Sensor diagnostics signed into logs.

Design traps & validation

  • ID-EEPROM is not an authenticator; reject ID-only substitutions.
  • Guarantee entropy and monotonic counters; define strict replay window.
  • Hot-plug/noise: debounce handshakes; atomic enable after success.
  • Tests: cold/hot-plug; low-temp RNG; replay must fail with reason="Replay".

Policy ok=true → allow (EN=1, nominal ILIM); ok=false → limit; hard fail → deny + log AuthFail.

Authentication handshake gating the EN signal Adapter/Pack SE ↔ MCU/Security Gateway → Power Path EN gate; nonce and counter protect against replay. Adapter / Pack SE HMAC / ECDSA ID · pubkey · key_slot MCU / Security Gateway nonce (chal) + counter verify(resp, alg) → ok/limit/deny expiry (exp) & revocation Power Path EN Gate ALLOW LIMIT DENY nonce · counter · alg · key_slot · exp → EN policy

Signed Switching: EN/PG/FAULT with Proof

Make action = evidence. Each critical power-path action produces a signed, non-replayable record tied to the rail and time base.

Event coverage

  • Actions: TurnOn, TurnOff, ILIMChange, PrioritySwitch, RCBTrip, ThermalShutdown.
  • Record: {"counter","ts","action","path_id","ilim","vdrop","temp","reason","mac"}
  • Reasons: AuthOK, AuthFail, OC, OT, OV, RCB, Manual.

Timing policies

  • Pre-sign then act for TurnOn/TurnOff (min repudiation; small enable delay).
  • Act then immediate sign for faults (≤10 ms window; sticky FAULT until persisted).

Counters, concurrency & durability

  • Monotonic counter per rail; include power-up index to detect resets.
  • Serialize commits across rails; no counter reuse across domains.
  • Append-only, hash/MAC-chained log; ring + sealed segments; double-write with CRC+MAC.
{
  "EventRecord": {
    "counter": 0, "ts": "UTC-ISO", "action": "TurnOn|TurnOff|...",
    "path_id": "railA", "ilim": 2.0, "vdrop": 0.06, "temp": 38.5,
    "reason": "AuthOK", "mac": "..."
  }
}
      

Targets event coverage ≥99%, lost-event ≤1e-6/switch, counter rollback = 0, pre-sign enable latency ≤3 ms typ.

Signed switching events with chained hashes and protected counters E1→E2→E3 with hash links; side callouts show EN state and ILIM before/after; a panel lists counter/ts/mac. E1: TurnOncounter=101 · ts=… E2: ILIMChangeold→new: 2.0→2.5 A E3: PrioritySwitchΔV_trip=30 mV EN: 0 → 1 ILIM: 2.0 → 2.5 A Fields: counter · ts · action · path_id · ilim · vdrop · temp · reason · mac Durability: append-only · hash/MAC chain · ring + sealed segments

Tamper-Proof Logs for Field Return

Build logs that are traceable, verifiable, and power-loss safe to support RMA and compliance without leaking sensitive data.

Storage architecture

  • Two-tier layout: Ring Area (recent/high-frequency) + Sealed Area (incident windows; append-only segments).
  • Write protocol: double-write → CRC → MAC; commit only after both copies pass CRC; track a commit_index.
  • Version & identity: bind log_version, device serial, and powerup_index to the monotonic counter domain.

Record skeleton

{
  "counter": 0, "ts": "UTC-ISO", "powerup": 7,
  "action": "TurnOn|TurnOff|ILIMChange|PrioritySwitch|RCBTrip|ThermalShutdown",
  "path_id": "railA", "ilim": 2.0, "vdrop": 0.06, "temp": 38.5,
  "reason": "AuthOK|AuthFail|OC|OT|OV|RCB|Manual",
  "hash_prev": "...", "mac": "..."
}

Power-loss consistency

  • Shutdown: flush ring tail, seal current segment, store checkpoint hash.
  • Boot: replay from checkpoint, verify chain, mark partial commits as chain breaks.
  • No RTC: order by counter + powerup_index; map coarse time in the cloud.

Privacy & access

  • Redaction: export ID-mapped fields; keep signatures verifiable at edge/cloud.
  • RBAC tiers: Maintenance (read/export), Development (decode redactions), Legal (full audit).
  • Transport: encrypted export packages with chain root and metadata.

Endurance & compression

  • Budget ring size for worst-case event rate × lifetime with wear margin.
  • Coalesce repetitive chatter (e.g., PG) into burst summaries; keep edges verbatim.
  • Even-wear across pages; batch writes to avoid tiny updates.

RMA workflow

  1. Bundle: ring tail + last N sealed segments + metadata (chain_root, log_version, serial, powerup_range).
  2. Cloud verify: recompute CRC/MAC/chain; flag gaps/dupes/rollback.
  3. Report: machine verdict + readable timeline + non-repudiation token.

Targets lost-commit ≤1e-6, chain-verify ≥99.999%, replay detection = 100%.

Ring and Sealed Log Areas with Hash/MAC Chain Left ring for recent events, right sealed segments chained by hashes; CRC/MAC badges; power-loss safety note. Ring Area (hot) wrap → overwrite oldest (checkpoint protects incidents) Sealed Area (cold, append-only) hash_prev → hash_curr → … (MAC) CRC MAC Power-loss safe: checkpoint on shutdown, replay on boot, partial commits are detected and quarantined.

Interface Binding to eFuse / Hot-Swap / OR-ing

Attach the security layer at concrete power-path signals. Policies decide enable/limit/deny; every action emits a signed event.

Binding points

  • eFuse: EN, ILIM, TIMER, FAULT, PG
  • Hot-Swap: GATE, TIMER, SOA_MON, FAULT, PG
  • Ideal-Diode / OR-ing: PRIORITY, ΔVtrip, RCB, PG

Policy templates

  • AuthOK: enable path (EN=1/GATE drive), nominal ILIM, normal priority.
  • AuthSoftFail: limit ILIM or delay/back-off; require extra confirmation.
  • AuthHardFail: deny/disable (EN=0/GATE off/RCB open); force signed audit event.
  • All actions: emit EventRecord (pre-sign for planned actions; bounded post-sign for faults).

Cross-domain semantics & stability

  • Normalize PG/FAULT to OK/Degraded/Failed across vendors.
  • Prevent priority ping-pong: hysteresis on ΔVtrip and hold-off timers.
  • Serialize event commits per rail; unique path_id per domain.

Black-box verification scripts

  • Probe PG/FAULT/EN; confirm event→action equivalence and ordering.
  • Inject ±ΔV noise; verify single decision per hold-off window.
  • Reverse current step → RCB trips; immediate block + post-sign within window; state sticky until persisted.

Targets pre-sign enable latency ≤3 ms typ; priority decision ≤1 per hold-off window; missed-event ≤1e-6/switch.

Signal to Policy Map with Signed Event Fields Left: signal pills (eFuse/Hot-Swap/OR-ing). Middle: policy blocks. Right: EventRecord fields. Signals eFuse · EN / ILIM / TIMER / FAULT / PG Hot-Swap · GATE / TIMER / SOA_MON / FAULT / PG OR-ing · PRIORITY / ΔV_trip / RCB / PG Policies AuthOK → enable, nominal ILIM AuthSoftFail → limit/back-off AuthHardFail → deny/disable All actions → signed event EventRecord fields countertsactionpath_id ilimvdroptempreasonmac Stability: ΔV_trip hysteresis + hold-off timers to prevent ping-pong; serialize commits; unique path_id per rail.

Cross-Brand Migration Paths

Keep the same authenticate → permit/limit/deny → signed log experience when swapping parts across brands for small-batch builds.

Mapping dimensions

  • Interface: I²C, 1-Wire/HDQ, proprietary sideband (clocking, pull-ups, hot-plug tolerance).
  • Algorithm: HMAC/CMAC vs ECDSA/EdDSA (key sizes, RNG quality, latency budget).
  • Objects: ID/cert, expiry, serial, revocation token; bind to monotonic counter + powerup_index.
  • Field names & lengths: canonical AuthResult and EventRecord with pad/truncate rules.
  • PG/FAULT semantics: normalize to OK / Degraded / Failed per vendor.

Canonical schemas (stable)

{
  "AuthResult": {"adapter_id","battery_id","chal","resp","alg","key_slot","exp","ok"},
  "EventRecord": {"counter","ts","action","path_id","ilim","vdrop","temp","reason","mac"}
}

Migration playbooks

  • Upgrade: ID-store → real authenticator (ATECC/SE050/STSAFE…). Gate EN by ok; enable revocation.
  • Lateral swap: change SE brand, keep canonical schemas; re-validate latency, entropy, counter continuity.
  • Rollback (auth down): enter SoftFail (reduced ILIM, back-off); continue full signed logging.

Cloud/edge mapper

  • Transform vendor payload → AuthResult/EventRecord.
  • Adapter for PG/FAULT, ΔV priority, RCB; versioned transforms with a schema registry.

Procurement seeds: “Authenticator required (ID-only parts unacceptable)”, “Expose nonce + counter + expiry + revocation”, “Provide field map & provisioning notes”.

Validation & Test Recipes

Bench-ready matrix to qualify authentication, timing, binding, and tamper-proof logging under real-world stress.

Bench & instruments

  • Programmable PSUs & E-loads (transient, surge, backflow); hot-plug/surge generator.
  • Time capture: logic analyzer + timestamped UART/SWD; PPS if available.
  • SE debuggers (ATECC/SE050/STSAFE); thermal chamber −20…+85 °C.

Test items & acceptance

  • Auth robustness: cold/hot-plug, UVLO, cable noise, low-temp RNG → success ≥99.9%, no enable without valid ok.
  • Replay protection: reuse chal/resp, counter rewind, offline re-inject, powerup tricks → 100% detection (Replay|CounterRollback).
  • Signature timing: pre-sign vs post-sign → pre-sign enable ≤3 ms typ; post-sign window ≤10 ms with sticky FAULT until persisted.
  • Log robustness: power cut during bursts; ring rollover; sealing → ≤1 partial record dropped; chain verify ≥99.999%.
  • Binding consistency: PG/FAULT/EN black-box → event→action equivalence; ordering preserved (mismatch rate 0).
  • Priority stability (OR-ing): ±ΔV noise → ≤1 decision per hold-off window; no ping-pong.
  • Thermal & aging: cycles for latency/counter; no rollback with drift.
  • Compliance tether: during IEC 61000-4-5, ensure minimal event fields (time, path, VIN/ILOAD flag, reason).

Golden vector (example)

{
  "pre": {"ilim": 2.0, "vdrop": 0.05, "temp": 32.0},
  "action": "TurnOn", "sign_mode": "pre",
  "expect": {"ok": true, "enable_delay_ms_max": 3, "event_pair": "present"}
}

Targets: false-allow ≤1e-6, false-deny ≤1e-3, lost-event ≤1e-6/switch, chain-integrity ≥99.999%, mean pre-sign latency ≤3 ms.

BOM Remarks & Procurement Hooks

Lock the “security hooks” into purchasing to prevent ID-only substitutions and keep the same user experience across brands.

Fixed BOM lines (copy & paste)

  • Power-path enable must be gated by adapter/battery cryptographic authentication.
  • All switching events must be digitally signed and logged with a non-replayable counter.
  • Cross-brand substitutions require cloud-side mapper updates and validation scripts.

Secure-element base (adapter/battery side)

  • Microchip ATECCATECC608B-TNGTLS (pre-provisioned), ATECC608B-MAHDA-T (flex slots). Reason: fast pilot, HMAC/ECDSA, good tooling.
  • NXP SE050SE050C (I²C). Reason: ECDSA/ECDH, secure counters, easy cloud pairing.
  • ST STSAFE-ASTSAFE-A110. Reason: attestation, counters, lifecycle; automotive options.

Bind to power-path signals (PG/EN/ILIM/RCB)

  • TITPS25982-Q1 (eFuse), TPS2491-Q1 (Hot-Swap), LM74700-Q1/LM5050-1-Q1 (Ideal-diode/OR-ing); optional BQ40Z50-R2, BQ28Z610-R1, TPS25750 for IDs. Reason: clean EN/ILIM/PG/RCB touchpoints.
  • RenesasISL9241 (SMBus charger), ISL94202 (monitor), RA4M1/RA6M3 (MCU+SCE). Reason: policy host + counters + PG gating.
  • onsemiNIS5020/NIS5135 (eFuse-like), NCP45520 (reverse-blocking switch), NCP81239 (Type-C/PD path). Reason: FAULT/RCB semantics available.
  • Melexis (diagnostic sources) — MLX91221 (current), MLX90614 (IR temp). Reason: enrich signed EventRecord context.

Packaging / temperature / lead-time layers

  • Package: prefer QFN with EP for thermal; specify exact suffixes.
  • Temp: −40…+85 °C vs AEC-Q100; state requirement per line item.
  • Supply tiers: Preferred / Alternate / Last-resort with MOQ; allow cut-tape for proto.

Production & service hooks

  • Serialization & key injection: allocate key_slot, counter domain, exp; archive provisioning log hash.
  • Returns/repairs: revoke → re-enroll; ship with RMA log pack (chain_root + sealed segments).

Acceptance for procurement: No ID-only substitutes; AuthResult present; signed EventRecord; mapper updated before shipment.

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

Minimal Data Objects & Cloud Mapper

Freeze canonical schemas and mapping rules so brands can be swapped without changing UX, policies, or logs.

Canonical schemas

{
  "AuthResult": {"adapter_id","battery_id","chal","resp","alg","key_slot","exp","ok"},
  "EventRecord": {"counter","ts","action","path_id","ilim","vdrop","temp","reason","mac"},
  "MapperRow": {"brand","device_family","bus","obj_map","limits","notes"}
}

Field & unit rules

  • Units: ilim[A], vdrop[V], temp[°C]; ts=UTC-ISO; counter=u64 mono.
  • Pad/truncate: short → left-pad; long → truncate + hash suffix (stable length).
  • Endian: counters big-endian; binary blobs base64.

Mapping strategy

  • Vendor payload → AuthResult/EventRecord via per-family obj_map.
  • Reason codes unified: {AuthOK,AuthFail,OC,OT,OV,RCB,Manual,Replay,CounterRollback}.
  • Dual consistency: edge signs; cloud verifies & stores. Keys never leave SE/factory.

Versioning & rollout

  • Schema version pinned to FW; gray release per SKU; one-click rollback in mapper registry.
  • New fields optional; old records render with defaults.

MapperRow stubs (with concrete PNs)

{
  "brand":"Microchip","device_family":"ATECC608B","bus":"I2C",
  "obj_map":{"chal":"nonce","resp":"sig","exp":"valid_to"},
  "limits":{"latency_ms_max":3},"notes":"TrustFLEX slots 0/2; counter=adapter-domain"
}
{
  "brand":"NXP","device_family":"SE050C","bus":"I2C",
  "obj_map":{"resp":"ecdsa_sig"},"limits":{"latency_ms_max":5},
  "notes":"ECDSA P-256; RNG self-test on boot"
}
{
  "brand":"ST","device_family":"STSAFE-A110","bus":"I2C",
  "obj_map":{"chal":"host_chal"},"limits":{"latency_ms_max":5},
  "notes":"Provision at factory; revoke via CRL update"
}
{
  "brand":"TI","device_family":"TPS25982-Q1","bus":"GPIO/I2C-host",
  "obj_map":{"PG":"pg","FAULT":"flt","ILIM":"ilim"},"limits":{"ilim_A_max":5},
  "notes":"Bind EN to AuthResult.ok; log ILIM changes"
}
{
  "brand":"Renesas","device_family":"ISL9241","bus":"SMBus",
  "obj_map":{"PG":"pg","EN":"enable"},"limits":{"latency_ms_max":3},
  "notes":"Use RA MCU for counters & MAC chain"
}
{
  "brand":"onsemi","device_family":"NIS5020","bus":"GPIO",
  "obj_map":{"FAULT":"flt","EN":"en"},"limits":{"latency_ms_max":3},
  "notes":"Pair NCP45520 for RCB semantics if needed"
}
{
  "brand":"Melexis","device_family":"MLX91221","bus":"Analog/I2C",
  "obj_map":{"current":"i","temp":"t"},"limits":{"sample_rate_Hz":2},
  "notes":"Inject context into EventRecord (not authenticator)"
}

Procurement must request: mapper JSON per PN, schema version, key provisioning note, and RMA export checklist.

FAQ

Concise, engineer-ready answers. Text below matches JSON-LD exactly.

Why do eFuse/Hot-Swap paths need cryptographic checks instead of simple ID pins?

Simple ID pins are cloneable and cannot prove authenticity. A challenge-response using a secure element returns AuthResult with nonce, counter, alg, and ok, letting firmware gate EN and ILIM decisively. Pairing authentication with signed EventRecord provides non-repudiation for field returns and blocks fake adapters or batteries that would otherwise bypass limits or logging.

How do I bind authentication results to EN/ILIM without adding boot latency?

Start nonce generation on cable detect, run authentication in parallel with rail settling, and prepare a pre-signed TurnOn plan. Enable only when AuthResult.ok is true; otherwise enter SoftFail with reduced ILIM. Typical added delay is within a few milliseconds. If the secure element is absent, hold EN off or time-box SoftFail until a signed result arrives.

What’s a safe minimal data set for a signed switching event?

Log an EventRecord containing counter, ts, action, path_id, ilim, vdrop, temp, reason, and mac, plus hash_prev to chain records. The counter gives strict ordering, the MAC proves origin, and the hash chain makes edits or deletions evident. Keep units canonical and persist quickly to survive power loss while preserving verification.

How do I prevent replay attacks if the device has no secure RTC?

Use a monotonic counter bound to powerup_index and verify a fresh nonce in every AuthResult. Reject responses with reused or decreasing counters and require a bounded verification window. On ingest, the cloud checks ordering and chain continuity. Coarse time can be reconstructed later; replay safety comes from counters, nonces, and chained MACed records.

Can I retrofit authentication on a legacy design with only PG/FAULT available?

Yes. Add a secure element on I2C or 1-Wire to the host MCU and gate EN in firmware while preserving the hardware path. Map PG and FAULT into reason codes and log signed EventRecord entries. If authentication is unavailable, enter SoftFail with reduced ILIM and limited retries, then enable normally after a valid, non-replayable result.

What’s the difference between ID EEPROM and real authenticators for adapter/battery?

ID EEPROM stores static bytes that are trivial to copy. Authenticators compute HMAC or ECDSA over a nonce and monotonic counter and can enforce expiry and revocation. Their AuthResult.ok directly gates EN and ILIM and their keys never leave the secure element. Keep EEPROM only for legacy traceability, not for admission decisions.

How do I make event logs tamper-evident yet power-loss resilient?

Use a ring area for hot events and a sealed append-only area for incidents. Write each record twice with CRC and MAC, include hash_prev to chain, and checkpoint on shutdown. On boot, replay and quarantine partial commits. The cloud verifies chain roots and detects edits, deletions, or counter rollbacks without storing private keys.

What failure modes should force “limited-current” instead of “deny-power”?

Use SoftFail when authentication stalls, entropy is marginal, PG is unstable, contact resistance likely increased, or thermal derating is needed. Lower ILIM, increase hold-off, and log the reason. Reserve HardFail for explicit AuthFail, reverse-current block events, or policy violations. Always emit a signed EventRecord so support can justify decisions later.

How do I validate cross-brand authenticators and keep a single cloud schema?

Adopt canonical AuthResult and EventRecord and a per-brand obj_map that normalizes fields, units, and reason enums. Verify latency budgets, counter monotonicity, and nonce freshness with golden vectors. Pin schema to firmware version and use dual consistency: the edge signs, the cloud verifies and stores. Avoid vendor-specific payloads in dashboards.

What counters/limits avoid wearing out NVM when logging frequent events?

Coalesce chatty PG transitions, batch writes, and size the ring for worst-case burst rates and lifetime wear. Use even-wear page rotation and quarantine partial commits. Keep counter as u64, chain integrity above 99.999 percent, and seal incident segments sparingly. Persist minimal fields first, then enrich asynchronously if bandwidth and wear allow.

How do I pass factory EOL tests if keys are injected late in the process?

Run pre-EOL with placeholder certificates marked non-shipping, verify power-path behavior, and capture baseline EventRecord. After key injection, perform one authenticated TurnOn cycle, lock counters, and export a provisioning hash for the RMA pack. Execute mapper sanity checks and latency tests, then flip the shipping bit and archive serialized key slot metadata.

For small-batch builds, what procurement notes prevent unsafe “ID-only” substitutions?

Require a secure element producing AuthResult with nonce, counter, expiry, and ok, and gate EN and ILIM on that result. Demand signed EventRecord, mapper JSON per PN, and schema version pinning. Allow SoftFail fallback but forbid ID-only parts. Specify AEC-Q or industrial temperature, exact packages, and cut-tape acceptance for prototypes.