What PEPS Does in the Vehicle

Keyless Entry & Start (PEPS) turns everyday actions like walking toward the car, touching the door handle and pressing the Start button into a secure, automated sequence. The driver does not need to press buttons on a key fob; the vehicle detects a valid key or digital key nearby and decides when to unlock and when to authorize an engine or inverter start.

It is useful to distinguish classic Remote Keyless Entry (RKE) from Passive Entry / Passive Start (PEPS) and modern digital keys. RKE typically relies on a key fob button and a single RF path. PEPS adds presence detection around and inside the vehicle so that doors unlock and the Start button is enabled automatically. Digital keys extend the concept by moving the credential into a phone, card or wearable using NFC, BLE or UWB links.

In a vehicle architecture, PEPS sits between the driver, the body electronics and the powertrain. It coordinates with the BCM and door modules to command lock and unlock, with powertrain and immobilizer functions to allow or block start, and with telematics and apps so that remote lock/unlock and cloud-managed digital keys still pass through the same authorization logic.

System-Level Architecture

A PEPS implementation links three main sides: the vehicle-side PEPS ECU with LF drivers, RF radios, security and power management; the key fob or digital key device; and the vehicle networks that connect PEPS decisions to body, gateway and powertrain controllers. The diagram below keeps this view at assembly level and avoids RF or cryptographic detail.

On the vehicle side, the PEPS ECU typically integrates multi-channel LF antenna drivers, one or more RF/BLE/UWB transceivers, a secure element or HSM, an application MCU and robust power and supervision. Key fobs concentrate on ultra-low-power LF wake-up and RF response, while phones or cards provide digital key functions through NFC, BLE or UWB frameworks. The ECU interfaces to body and gateway controllers over CAN, LIN or Ethernet, carrying lock/unlock, diagnostics and start authorization signals.

LF / HF Radio Channels for PEPS

In a PEPS system the radio channels are tuned to a very specific role: low-frequency fields are used for presence detection and in-cabin vs. out-of-cabin decisions, while higher-frequency paths carry the key response or digital key traffic. This section focuses on what makes LF and HF radio channels special in a PEPS context, rather than generic RF design theory.

LF drivers and antennas define where the vehicle believes the key can be, while UHF, BLE or UWB links carry cryptographically protected responses under tight EMC constraints. Detailed matching, link budget and PA/LNA architectures belong in the RF transceiver and 125 kHz driver domains; here we stay at the assembly level and highlight requirements that affect PEPS module selection and layout.

LF Path for Presence Detection

Most automotive PEPS implementations use a 125 kHz low-frequency field for presence detection and wake-up. The LF channel is intentionally short-range and predictable, making it suitable for deciding whether a key is near the door, inside the cabin or well outside the vehicle. LF communication is simple, but the spatial behaviour of the field is central to anti-relay strategies and false-accept avoidance.

Vehicle-side antennas are typically split into exterior LF antennas around door handles, tailgate and bumper areas, and in-cabin LF antennas in the console and cabin zones. Exterior antennas must provide enough coverage for typical standing positions near the vehicle without leaking far into the street, while in-cabin antennas must reliably detect a key inside the cabin but attenuate quickly outside. Together they allow the PEPS ECU to separate “outside key, unlock only” from “inside key, start permitted”.

LF antenna driver ICs therefore need adequate current drive for multiple coils, flexible modulation support and robust diagnostics. Multi-channel drivers must energise several antennas, shape field strength across the body and report open/short faults on each coil. Built-in diagnostics and monitoring are important both for basic reliability and for safety arguments where PEPS decisions are treated as part of a safety-relevant chain.

HF / UHF / 2.4 GHz / UWB Return Channel

The return path from key or digital key device back to the vehicle can be implemented with classic UHF channels at 315/433/868/915 MHz, newer BLE-based links around 2.4 GHz or even UWB for precise ranging. Many platforms combine more than one of these, for example UHF for legacy fobs, BLE for phone-as-a-key and UWB for fine-grained distance checks. Each variant has different coverage, latency and coexistence behaviour.

From a PEPS perspective, the RF transceiver must meet automotive-grade robustness, sensitivity and blocking performance under real-world interference. It must still decode a valid key reply when TPMS, remote keys, telematics and nearby vehicles are active. Many devices add integrated rolling-code logic or AES engines so that encrypted responses can be generated close to the physical layer, while long-term key storage and security policy remain anchored in secure elements or HSMs.

System designers also care about link timing and coverage: the response channel must work when the key is in pockets or bags and it must respond quickly enough that unlock and start feel instantaneous. Those constraints feed directly into RF front-end choice, antenna placement and coexistence strategy, which are covered in the dedicated automotive RF transceiver and antenna design domains.

EMC and Coexistence Constraints

PEPS radio channels operate inside a crowded RF environment. The vehicle already hosts TPMS, remote start systems, radars, ultrasonic sensors, telematics, Wi-Fi, Bluetooth, GNSS and in some cases V2X. PEPS links, especially the UHF and BLE/UWB paths, must therefore tolerate interference, avoid self-jamming other systems and remain within regulatory and OEM EMC limits over the vehicle lifetime.

For PEPS module selection this translates into requirements on blocking, intermodulation and spurious emissions, suitable front-end filtering and careful antenna placement relative to other RF subsystems. Detailed EMC test plans, standard references and board-level mitigation will be treated in the EMC / EMI subsystem topic; here the key message is that PEPS radio paths must be treated as security-relevant links when defining co-existence and EMC budgets.

Security Path & Anti-Relay Design

PEPS security is built as a system path rather than a single cryptographic feature. Threats such as relay attacks, key cloning and RF jamming must be handled with a combination of secure elements or HSMs, authenticated radio links, LF field geometry, UWB ranging and behavioural logic. This section stays at the architectural level and focuses on how the security path is assembled across ICs and ECUs.

Details of AES and ECC algorithms, key ladder implementations or back-end PKI provisioning are best treated in the security and digital key domains. Here the emphasis is on what a PEPS module must provide: protected key storage, hardware-assisted cryptography, secure boot and measured responses to relay and jamming scenarios, all integrated into body, gateway and powertrain logic.

Threat Models for PEPS

The most widely discussed PEPS attack is the relay attack, where attackers place one device near the car and another near the key and forward LF and RF traffic between them. The vehicle sees responses that look correct but does not realise the key is actually far away. Other threats include key cloning or key extraction, in which long-term keys are copied out of a fob or ECU, and jamming or denial-of-service of the RF return channel.

All of these attacks aim at unauthorised unlock or start. A robust PEPS security path must therefore not only protect keys and authenticate messages, but also embed checks on timing, location and user behaviour. That is where secure elements, HSMs, UWB ranging, LF antenna patterns and application-level state machines come together.

Secure Elements and HSM in PEPS

On the vehicle side, PEPS architectures usually rely on either a discrete secure element or an MCU with an integrated hardware security module (HSM). In both cases, long-term keys are stored in a protected hardware boundary and challenge–response operations are executed without exposing keys to the application code. The security block also supports hardware-accelerated AES, often with true random number generation, secure boot and secure firmware update capability.

The HSM or secure element is typically coupled to the PEPS application MCU and to secure network features such as authenticated CAN, FlexRay or Ethernet. From an IC selection viewpoint the key questions are support for AES-128/256, availability of automotive security certifications, integration of TRNG and anti-tamper features, and how well the device fits into the OEM's broader security framework.

On the key or digital key side, secure MCUs or security blocks protect the credential used in PEPS flows. They must balance low power consumption with resistance to basic physical and side-channel attacks. The detailed design of those protections is usually covered in the secure microcontroller and digital key topics; from a PEPS perspective it is enough to ensure that keys are not stored in plain MCU flash and that the key device can participate in authenticated protocols defined by the vehicle.

Authentication Flows and IC Requirements

Legacy RKE systems historically used rolling-code schemes, where a counter and shared secret produce a new value for each button press. Modern PEPS flows are more often based on challenge–response with symmetric keys, using AES to compute a response that is valid only for a given challenge and key. For digital key deployments, frameworks specified by bodies such as the Car Connectivity Consortium and ISO define how these primitives are used over BLE, UWB or NFC.

Across all of these patterns, the PEPS ECU must host hardware-assisted cryptography, secure key storage and a state machine that refuses stale or replayed messages. That drives requirements on MCUs, secure elements and RF devices: AES accelerators, secure key slots, support for required digital key profiles and interfaces that let security blocks work closely with LF and RF channels without leaking sensitive material.

Anti-Relay Techniques in PEPS Design

Relay resistance is achieved through layered techniques. The LF field already provides a spatial constraint: antenna placement and drive levels can be tuned so that the region where a key correctly receives LF challenges roughly matches where a real driver can stand. Combined responses from interior and exterior antennas allow the ECU to distinguish “outside key” from “inside key” and to enable only unlock or both unlock and start accordingly.

UWB time-of-flight ranging adds a distance dimension. Because UWB exchanges can measure propagation time with fine resolution, simple relay devices cannot forward signals without introducing detectable delay. Many recent PEPS concepts therefore combine LF for directionality and UWB for distance, feeding both into the PEPS state machine and safety logic.

Finally, behavioural logic acts as a human-in-the-loop check. Requiring the driver to touch the handle, press a button on the door or press the Start button with the brake applied ensures that physical interaction at the vehicle matches the electronic view of key presence. When combined with LF patterns, UWB ranging and secure elements, these measures form a system-level security path rather than relying on any single component in isolation.

Power Architecture & Low-Power Behaviour

A PEPS system must balance two very different power profiles. On the key fob side, the target is multi-year battery life with only brief active windows for wake-up and response. On the vehicle side, PEPS logic must remain available while respecting tight vehicle sleep-current budgets and integrating with body domain power strategies such as KL30 and KL15. This section focuses on those system-level power decisions.

Key devices rely on deep sleep modes, ultra-low standby current in LF and RF front-ends and short, one-shot transmissions during authentication. The PEPS ECU must in turn be placed in suitable power domains so that lock/unlock and start authorisation are still possible when most of the vehicle is sleeping, and it must provide controlled fall-back behaviour in low-voltage or ECU-fault situations.

Key Fob Power and Low-Power Operation

Typical key fob designs aim for a battery life in the 2–5 year range with minimal user intervention. For most of that time the key is in deep sleep, with only a low-frequency receiver and minimal housekeeping logic active. When the LF path detects a valid wake-up pattern, the MCU and RF path briefly wake, process the PEPS protocol and send one or more replies before returning to a low-power state.

Achieving such lifetimes requires careful use of MCU sleep modes, LF front-end standby current and RF transmit behaviour. The MCU must offer very low deep-sleep current with fast wake-up on LF or timer events, while the LF receiver must monitor the field with microamp-level current. RF or BLE/UWB paths are designed for short, one-shot transmissions that are powered only for the duration of the PEPS exchange, then shut down again to minimise average current draw.

Coin-cell management ICs can support this strategy by providing regulated rails, low-power voltage monitoring and brown-out reporting without adding significant quiescent load. From an IC selection perspective, deep-sleep current, wake-up latency and LF/RF standby currents are just as important as peak transmit current or RF performance when planning key fob BOMs.

Vehicle-Side Power Domains and Wake-Up Strategy

On the vehicle side the PEPS ECU sits between always-powered domains and switched body supplies. Some platforms keep the PEPS ECU on a KL30-like always-on feed so that it can respond to lock/ unlock and key proximity at any time. Others place part of the PEPS logic into a partition that can be powered down, leaving only minimal wake-up and monitoring functions online to meet very low sleep-current targets.

Integration with body domain supplies such as KL15 for ignition-on functions and comfort power domains determines which PEPS features are active in each vehicle state. For example, a design may allow unlock and basic key detection in deep sleep, but reserve full PEPS diagnostics and extended digital key services for KL15 or comfort-on states where higher current draw is acceptable. These choices must be lined up with OEM-level specifications for static current and wake-up behaviour.

In low-voltage and loss-of-power scenarios, the power architecture must define clear fall-back paths. These can include mechanical key cylinders for door entry, backup NFC zones that work without a key battery and limited start authorisation workflows executed by a reduced set of ECUs. Planning these behaviours early ensures that PEPS does not become a single point of failure when the vehicle power system is stressed.

Power IC Requirements for PEPS Modules

The PEPS ECU itself typically relies on automotive-grade LDOs or DC-DC converters with low quiescent current, robust protections and wide input ranges. Power ICs must handle supply transients inherited from the body domain, provide clean rails for LF, RF, MCU and security blocks and support brown-out detection and reset behaviour that maintains a consistent security state. Watchdog functions are often required so that stalled PEPS software does not silently leave the vehicle in an unsafe state.

On the key fob and digital key side, coin-cell power management ICs and low-IQ regulators are selected for minimal quiescent load and predictable behaviour over temperature and battery ageing. Combined with carefully chosen MCU sleep strategies and RF duty cycles, these components allow the PEPS system to deliver the desired user experience without sacrificing battery life or vehicle-level sleep-current budgets.

Integration with Body, Gateway and Diagnostics

A PEPS module does not operate in isolation. It sits within the body domain, collaborates with door modules and BCM for lock and handle functions, feeds start authorisation into powertrain and immobilizer logic and reports diagnostics and security events through gateways and telematics. This section describes how PEPS fits into the wider vehicle architecture.

Understanding these interfaces early helps avoid ambiguous ownership of door handle signals, duplicated start logic or diagnostic blind spots. It also defines how PEPS faults and security alerts will surface to drivers, workshops and backend systems over the lifetime of the vehicle.

Boundaries with BCM and Door Modules

In most architectures, door lock actuators and window lifters are driven by door modules or a central BCM, not directly by the PEPS ECU. The PEPS module issues lock and unlock requests and key presence information, while body controllers enforce local constraints such as anti-pinch, child lock settings and door state. Keeping motor drive and PEPS authorisation separate improves modularity and simplifies thermal and fault handling.

Door handle touch or button signals can be wired either to door modules or to the PEPS ECU, depending on platform lineage. If they terminate at door modules, events are forwarded over LIN or CAN for PEPS logic to consume. If they terminate at the PEPS ECU, the body network carries only higher-level lock and status messages. In zonal architectures, PEPS functions may be integrated into zonal controllers, but the same boundary questions need to be answered up front.

The choice between LIN, CAN and zonal Ethernet for these paths affects latency, diagnostic granularity and wiring complexity. Regardless of network technology, it should remain clear which ECU owns door handle inputs, which ECU owns lock actuators and where PEPS state machines and safety checks actually run.

Integration with Powertrain and Immobilizer

Start authorisation relies on a clean signal chain from PEPS to powertrain and immobilizer functions. The PEPS ECU decides whether a valid key is present in the correct zone and exports a start authorisation status over CAN or Ethernet. A BCM or gateway combines this status with brake pedal, gear selector, door status and other safety-related signals before sending a final start-permit or inhibit message to the engine or inverter controller.

Some platforms keep immobilizer functions in a dedicated security ECU or inside the powertrain ECU, with PEPS supplying only a higher-level "key accepted" indication. Others integrate PEPS and immobilizer logic more tightly. In both cases, it is important that responsibilities are clearly documented so that security updates, fault trees and safety cases reference the correct ECU and signal names.

Typical fault conditions such as "key not in vehicle", "key battery low" or "start denied" must propagate back to the instrument cluster or HUD with meaningful messages. PEPS and powertrain integration therefore includes not just data paths, but also the strategy for how different rejection reasons are communicated to the driver and logged for later analysis.

Diagnostics, Security Logging and Remote Updates

Diagnostic coverage for PEPS spans hardware and security-related events. Hardware-oriented DTCs include LF antenna open or short circuits, missing key responses, RF receive errors and internal ECU faults. These codes are stored in the PEPS ECU or hosting body controller and exposed over CAN or Ethernet so that workshops can access them through standard diagnostic tools.

On top of DTCs, security logs capture events such as repeated failed unlock attempts, invalid credentials, suspected relay patterns or RF jamming indications. These logs may be aggregated by a gateway or telematics ECU and forwarded to backend systems, giving OEMs a way to monitor attack patterns and adjust security policies over time. They can also help explain intermittent "key not detected" complaints when RF conditions are marginal.

PEPS integration with OTA infrastructure is equally important. ECUs that implement PEPS or related security functions should support secure boot and authenticated firmware updates, with rollback options if an update fails. While the detailed OTA protocols belong to connectivity and security topics, PEPS designers must ensure that their module can be updated without violating safety or immobilizer constraints.

Safety, Misuse Scenarios & Compliance

PEPS sits at the intersection of safety, security and usability. It must not unlock or start a vehicle for the wrong key or a relay device, but it also must not frustrate drivers by refusing to operate when a valid key is present. On top of this, the system has to behave predictably in misuse and emergency scenarios and comply with functional safety, cybersecurity and RF regulations across all target markets.

This section takes a system-level view rather than repeating security or RF theory. It outlines how PEPS contributes to overall vehicle safety goals, how certain misuse and emergency cases are handled, and which standards and regulations typically shape PEPS design and validation.

Balancing Safety, Security and Availability

From a safety perspective, PEPS must avoid false accepts: the vehicle must not unlock or start for an attacker, a cloned key or a relayed signal. At the same time, from a usability and security-operations perspective it must minimise false rejects: legitimate drivers with valid keys should not repeatedly see "key not detected" or "start refused" in normal parking, garage and roadside environments.

The PEPS architecture manages this balance by layering mechanisms. LF field geometry and antenna placement constrain where the key can be seen, UWB ranging adds distance checks, secure elements and HSMs authenticate credentials and behavioural logic requires human actions such as touching the handle or pressing the Start button with the brake applied. The combination aims to make relay attacks and key cloning difficult while keeping everyday operation smooth for authorised users.

Functional safety and SOTIF provide the framework for analysing these behaviours. ISO 26262 focuses on faults that could cause incorrect PEPS decisions, while SOTIF (ISO 21448) covers risks that arise from limitations in the design or in the intended operating domain. Misuse scenarios such as harsh RF environments, congested parking areas or unusual user habits are key inputs to these analyses.

Misuse and Emergency Scenarios

PEPS must also behave safely when the vehicle is used in ways that do not strictly match the ideal use case. One recurring concern is children or pets left in the vehicle. Automatic lock strategies that re-lock the car after a timeout or when the key leaves the area must be coordinated with occupancy detection, HVAC and body logic so that the vehicle does not silently trap occupants in hot or cold conditions. OEMs typically define clear rules for when auto-lock is allowed and when it should be suppressed or delayed.

Another misuse scenario is leaving the key in the vehicle or trunk. PEPS and body controllers usually implement protections against locking a key inside: for example, preventing central locking when key presence is detected in the cabin or trunk, or automatically unlocking if a trunk is closed with a key detected inside. These behaviours must be tuned so they do not create new security gaps while still avoiding common user traps.

In emergency situations such as a severe crash or airbag deployment, door lock behaviour is often overridden by safety logic. The vehicle may automatically unlock doors or relax certain child-lock or central-lock constraints to support escape and rescue. In these modes, PEPS authorisation decisions are subordinated to higher-priority safety functions so that a missing key or RF disturbance does not prevent occupants from exiting the vehicle or first responders from gaining access.

Standards, Regulations and Compliance Landscape

Several standards and regulations shape the design and validation of PEPS systems. On the functional safety side, ISO 26262 requires that PEPS-related safety functions such as start authorisation and door lock control be analysed for hazards, assigned appropriate ASIL targets and equipped with suitable safety mechanisms. ISO 21448 (SOTIF) adds expectations for handling performance limitations and unforeseen scenarios even when no hardware fault is present.

Cybersecurity engineering is typically guided by ISO/SAE 21434 and UNECE regulations such as R155 and R156. These define how PEPS should be covered in threat analysis and risk assessment, how cybersecurity controls and monitoring are planned and how software updates, including PEPS-related fixes, are managed over the vehicle life. Logging of security events and the ability to patch vulnerabilities through secure OTA updates are practical outcomes of these requirements.

RF operation of PEPS channels must comply with spectrum regulations in all intended markets. Low-frequency, UHF, 2.4 GHz and UWB transmissions are subject to regional rules in Europe, the United States, China, Japan and other regions that limit frequency bands, radiated power, duty cycle and emissions. These constraints feed back into antenna design, wake-up strategies and achievable range, and must be factored into PEPS system requirements from the outset rather than treated as a last-step certification issue.