USB-C Power Delivery: PD 3.2, EPR, Negotiation and Charger Authentication

USB-C charging starts at 5 V; resistors on the CC wire allow up to 3 A. For more, the charger sends Source_Capabilities, the device sends a Request, and the charger answers Accept and PS_RDY before the voltage rises. Extended Power Range reaches 240 W at 48 V only with a 50 V, 5 A e-marked cable. Charger authentication is optional.

This post goes one level below our look at charging ports, the EU rule and juice jacking and opens the specifications themselves: CC voltages, Request bits, EPR entry, the authentication exchange and the Linux files that show what your charger offered. Numbers come from USB Power Delivery Revision 3.2 Version 1.2, USB Type-C Release 2.5 and the USB Type-C Authentication and Security Foundation specifications, all from the USB-IF document library.

Key takeaways

• The CC wire comes first. The charger's Rp pull-up against the device's 5.1 kΩ Rd sets default, 1.5 A or 3.0 A at 5 V.
• A PD contract is four messages. Source_Capabilities, Request, Accept and PS_RDY, each acknowledged with GoodCRC, at about 300 kbps on CC.
• EPR adds 28, 36 and 48 V, for 140, 180 and 240 W. The charger must first read the cable's e-marker and see 50 V, 5 A and EPR Capable.
• PPS and AVS let the device set the voltage. PPS uses 20 mV steps and a charger enforced current limit; AVS uses 100 mV steps without one.
• USB Type-C Authentication is real but optional. X.509 certificates, ECDSA P-256 and SHA-256; the USB-IF program launched on 2 January 2019. We found no public deployment figures.
• "Charge only" is not "no communication". Without data wires there is no USB session, but CC still carries PD messages.
• The EU requires USB-C, and USB PD above 15 W. Phones and eleven other categories since 28 December 2024; laptops since 28 April 2026.
• Linux shows the negotiation for free. /sys/class/typec and /sys/class/usb_power_delivery expose the power mode and every advertised power object, if your driver reports them.

A dated timeline of USB-C power and authentication

Dates come from the revision history tables inside each specification and from the regulator and press pages listed in the sources.

One inconsistency: the PD 3.2 Version 1.2 cover says 19 August 2026, but its own revision table lists January 2026.

How do the CC lines, Rp and Rd resistors and default USB power work before PD starts?

A USB-C receptacle has two configuration channel pins, CC1 and CC2. A cable connects only one of them end to end, which is how each side learns the plug orientation. Before a single PD message is sent, the CC wire does three jobs: it detects attachment, sets which side is the power source, and advertises how much current is available at 5 V.

Rp on the source, Rd on the sink

The PD specification summarises the first step plainly: the source asserts Rp, a pull-up, on CC, and the sink asserts Rd, a pull-down. The Type-C specification gives the values. The sink side is simple: Rd is 5.1 kΩ to ground, with a ±20% version that cannot tell current levels apart and a ±10% version that can. A ±20% voltage clamp at 1.1 V is also allowed, but the Type-C specification notes that it "inhibits USB PD communication", so a sink must switch to the resistor once it wants to talk PD.

The source side encodes its offer in the strength of the pull-up. Table 4-27 of Type-C Release 2.5 allows three implementations:

Legacy adapters, such as a USB-A to USB-C cable, must put a 56 kΩ ±5% Rp in the Type-C plug, because the old USB-A port cannot be trusted to supply more than default power.

Worked example 1: what voltage does the phone see?

The sink measures the voltage on CC and compares it to the windows in Table 4-36 of the Type-C specification: vRd-USB is 0.277 to 0.612 V, vRd-1.5 is 0.746 to 1.164 V and vRd-3.0 is 1.369 to 2.042 V. Do the arithmetic for a charger using pull-up resistors to 5 V and a sink with the nominal 5.1 kΩ Rd:

• 56 kΩ pull-up: 5 V × 5.1 ÷ (56 + 5.1) = 5 × 5.1 ÷ 61.1 ≈ 0.42 V. That sits in vRd-USB, so the phone draws only default USB power.
• 22 kΩ pull-up: 5 × 5.1 ÷ 27.1 ≈ 0.94 V, inside vRd-1.5. The phone may draw 1.5 A, or 7.5 W.
• 10 kΩ pull-up: 5 × 5.1 ÷ 15.1 ≈ 1.69 V, inside vRd-3.0. The phone may draw 3 A, or 15 W.

The current source version gives almost the same numbers: 80 µA × 5.1 kΩ ≈ 0.41 V, 180 µA × 5.1 kΩ ≈ 0.92 V, 330 µA × 5.1 kΩ ≈ 1.68 V. The windows are deliberately wide, with guard bands between them (0.613 to 0.745 V and 1.165 to 1.368 V), so resistor tolerance, cable resistance and ground offset cannot push one advertisement into the next.

Ra, VCONN and the e-marker

A third resistor, Ra, matters for cables. Before power is applied to the VCONN pin, a powered cable presents Ra on it, which tells the source that an electronically marked cable is present. The source then supplies VCONN on the unused CC pin to power the e-marker chip in the plug. That chip answers PD messages addressed to the cable, which is how the charger later learns whether the cable is rated for 3 A or 5 A and whether it is EPR capable.

Default power and the order of precedence

The Type-C specification ranks every 5 V power method. USB Battery Charging 1.2 supersedes plain USB 2.0 and USB 3.2 power, Type-C Current at 1.5 A and 3.0 A supersedes Battery Charging, and USB PD supersedes Type-C Current. Default USB power itself is defined by the data specification in use: 500 mA for USB 2.0 ports and 900 mA or 1,500 mA for USB 3.2 ports, depending on lane configuration. The Type-C specification also requires every port to tolerate a legacy charger that simply supplies VBUS all the time.

The practical meaning: a phone plugged into a basic USB-C charger with no PD controller still gets up to 15 W, purely from the Rp value, and never exchanges a message. Everything above 5 V requires PD.

What messages does a PD negotiation exchange?

PD messages travel on the CC wire, not on VBUS and not on the USB data pairs. The physical layer uses Bi-phase Mark Coding, which the PD specification describes as a version of Manchester coding, at a nominal bit rate of 300 kbps (270 to 330 kbps allowed). Each packet starts with a 64 bit preamble of alternating ones and zeros, then a start of packet marker, a header, up to seven 32 bit data objects in a normal message, a CRC and an end of packet marker. The receiver confirms every message with a GoodCRC control message; a message that is not acknowledged is retried.

The four messages of an SPR contract

The PD specification describes three contract states. A Default Contract is the 5 V power set by Rp at attach. An Explicit Contract is what exists after a successful negotiation. An Implicit Contract is a short 5 V state after a power role swap. The negotiation from Default to Explicit is an Atomic Message Sequence:

1. Source_Capabilities (data message type 00001b). The charger sends a list of Power Data Objects (PDOs). Each PDO is 32 bits; the top two bits give its type: fixed supply, battery, variable supply, or an Augmented PDO (APDO) for PPS and AVS. The first PDO is always the 5 V fixed supply. In Standard Power Range (SPR), the message holds the 5 V object plus up to six more. Until a sink answers, a source resends its capabilities every 100 to 200 ms (tTypeCSendSourceCap), up to 50 times (nCapsCount).
2. Request (data message type 00010b). The phone picks one PDO by its position and returns a single Request Data Object (RDO) with the operating current or power it wants and a few flags: Capability Mismatch, USB Communications Capable, No USB Suspend, Unchunked Extended Messages Supported and EPR Capable.
3. Accept (control message type 00011b). The charger agrees. If it cannot meet the request it answers Reject or Wait instead.
4. PS_RDY (control message type 00110b). The charger changes its output, waits for it to settle and announces that the new supply is ready. In SPR mode the sink waits up to 450 to 550 ms (tPSTransition) for this message before treating the attempt as failed.

Only then does the voltage on VBUS rise from 5 V to, say, 20 V. A sink must not draw more than the old contract allows during the transition.

What a typical 65 W negotiation looks like

Here is the same flow written as a trace, for a hypothetical 65 W charger and a laptop. It is illustrative, built from the message definitions, not captured from a device.

attach    CC: source Rp = 3.0 A advertisement, sink Rd = 5.1 kΩ   (Default Contract, 5 V)
SRC->SNK  Source_Capabilities
            PDO1 Fixed  5 V  3.00 A   (EPR Capable=0, USB Comms Capable=1, Dual-Role Data=1)
            PDO2 Fixed  9 V  3.00 A
            PDO3 Fixed 15 V  3.00 A
            PDO4 Fixed 20 V  3.25 A
            PDO5 PPS   5.0-21.0 V  3.25 A
SNK->SRC  GoodCRC
SNK->SRC  Request   ObjectPosition=4, OperatingCurrent=3.25 A, MaxCurrent=3.25 A
SRC->SNK  GoodCRC
SRC->SNK  Accept
SNK->SRC  GoodCRC
          (source slews VBUS from 5 V to 20 V)
SRC->SNK  PS_RDY
SNK->SRC  GoodCRC                                          (Explicit Contract, 20 V at 3.25 A)

After an Explicit Contract exists, the two sides can swap data or power roles (DR_Swap, PR_Swap), swap which end powers VCONN, exchange Vendor_Defined messages to discover identities and alternate modes such as DisplayPort, or enter USB4. The PD specification is explicit that vendor defined messages "Shall Not be used for direct power Negotiation".

Message types you will see in logs

A Hard Reset is not a message at all. It is a special ordered set of K-codes that tells both sides to return the supply to default and start over, and it is the failure path for most of the timers in this post.

What is Extended Power Range up to 240 W, and why does it need 5 A e-marked cables?

USB PD up to Revision 3.0 topped out at 100 W, from 20 V at 5 A. The USB-IF's own page puts the change plainly: PD 3.1 is "a major update to enable delivering up to 240W" over a full featured USB-C cable. Revision 3.1 split the protocol into two modes. Standard Power Range (SPR) is the classic mode with 5, 9, 15 and 20 V fixed supplies. Extended Power Range (EPR) adds 28, 36 and 48 V fixed supplies, for 140, 180 and 240 W at 5 A, and an EPR Adjustable Voltage Supply.

Why 5 A and 50 V

The Type-C specification rates the receptacle for 5 A, but standard USB-C cables are rated for 3 A. Any cable that carries more than 3 A must be electronically marked. EPR goes further: Type-C Release 2.5 requires EPR cables to support "a reported 50 V and 5 A operation", to work up to at least 50.9 V, and recommends that components on the VBUS path be rated for 63 V. The cable's e-marker must report 50 V, 5 A and the EPR Capable bit. A 48 V supply at 5 A is 240 W; the same supply through a 3 A cable would be 144 W, and through an unmarked cable the charger cannot know what it is driving at all. That is why the charger checks the cable before it raises the voltage, not after.

The eight steps of EPR entry

Section 7.30 of the PD specification sets the preconditions: the sink must ask, the source must verify the cable, there must be no charge through accessory in between, the two sides must already have an SPR Explicit Contract, the EPR Capable bit must be set in the source's 5 V PDO, and the EPR Capable bit must have been set in the sink's last Request. Then, in order:

1. The sink sends EPR_Mode (Enter) with its operational power.
2. The source checks the EPR Capable bit in the last Request and in its own 5 V PDO and confirms it can still offer EPR. If any check fails it sends EPR_Mode (Enter Failed) with a reason code and stays in SPR. Otherwise it sends EPR_Mode (Enter Acknowledged).
3. If the sink receives anything else, it initiates a Soft Reset.
4. If the source already knows the cable, or has a captive cable, it may skip ahead. If it knows the cable is not EPR capable, it fails with reason "Cable not EPR Capable".
5. If the source is not the VCONN source, it sends VCONN_Swap so it can power and talk to the e-marker.
6. The source sends the Discover Identity command to the cable plug and checks three fields: maximum VBUS voltage 50 V, current handling 5 A and EPR Capable set. No answer, or a wrong answer, means Enter Failed.
7. The source sends EPR_Mode (Enter Succeeded) and enters EPR mode.
8. The sink enters EPR mode, or initiates a Soft Reset if it received something else.

The whole exchange must finish within tEnterEPR, 450 to 550 ms, measured from the GoodCRC that acknowledged the Enter message, or the sink soft resets. Once in EPR mode the source sends EPR_Source_Capabilities within tFirstSourceCap (250 ms at most), and the sink must answer every one of those with an EPR_Request.

Keep-alive and safety rules in EPR

EPR mode is not set and forget. The PD timer table pairs a sink keep-alive interval, tSinkEPRKeepAlive, of 250 to 500 ms with a source side timeout, tSourceEPRKeepAlive, of 750 to 1,000 ms. The sink sends an EPR_KeepAlive extended control message on that schedule so the source knows the high voltage partner is still there and still in EPR mode. Power transitions take longer too: tPSTransition in EPR mode is 830 to 1,020 ms, against 450 to 550 ms in SPR mode.

Section 3 adds source rules. An EPR source may stay in SPR mode for anything up to 100 W. If the attached cable is not EPR capable, an EPR source must operate only in SPR mode. And in an EPR AVS contract the source must reject any request whose current exceeds the advertised power divided by the requested voltage, or 5 A.

Worked example 2: how much current at each EPR voltage?

Table 3.5 of the PD specification derives EPR offers from the port's maximum power (PDP). For fixed supplies:

Now the numbers:

• A 140 W charger. 28 V at 140 ÷ 28 = 5 A. No 36 V or 48 V offer.
• A 180 W charger. 28 V at 5 A (140 W) and 36 V at 180 ÷ 36 = 5 A (180 W).
• A 240 W charger running EPR AVS at 30 V. Available current is PDP ÷ voltage, capped at 5 A: 240 ÷ 30 = 8 A, capped to 5 A, so 150 W. At 48 V, 240 ÷ 48 = 5 A, so the full 240 W.
• The same 240 W charger at 15 V AVS. 240 ÷ 15 = 16 A, capped to 5 A, so 75 W. Low voltage EPR AVS is current limited, which is why high power laptops request high voltages.

What are PPS and AVS, and why do phones use them?

Both let the device set the voltage instead of picking from a short list. They differ in step size, range and who limits the current.

PPS: Programmable Power Supply

The PD specification defines PPS as an SPR supply whose voltage "can be programmatically adjusted in small increments" with a programmable current fold back. A PPS Request asks for an output voltage in 20 mV units and an operating current in 50 mA units. The charger keeps the current at or below the requested limit by lowering its voltage, which means it behaves like a constant current source when the phone's battery wants more than the limit.

Table 4.2 of PD 3.2 Version 1.2 gives the PPS ranges:

Older material, including our own earlier post, describes PPS as starting at 3.3 V. The current specification lists a minimum voltage field value of 33 (3.3 V) as "Deprecated" and 50 (5 V) as the required value. Chargers built to earlier revisions may still advertise 3.3 V; new designs start at 5 V.

PPS also has a keep-alive. The sink must send a Request at least every tPPSRequest (10 s at most), and the source's timeout, tPPSTimeout, is 12 to 15 s. A phone that stops talking gets dropped out of PPS.

Worked example 3: encoding a PPS request. A phone wants 8.24 V at 3.0 A from a PPS APDO. The voltage field is 8.24 V ÷ 0.02 V = 412. The current field is 3.0 A ÷ 0.05 A = 60. As the battery fills, the phone sends new Requests with slightly higher voltages, for example 8.30 V (field value 415), so the difference between charger output and battery voltage stays small.

Why phones prefer PPS

The gap between supply voltage and battery voltage has to be dropped somewhere. From a fixed 9 V supply, the phone's own converter does it, as heat next to the battery. With PPS the charger sets its output close to what the battery needs, so the loss stays in the charger. That is why a PPS capable phone can charge faster from a PPS charger than from a fixed PD charger with the same wattage.

AVS: Adjustable Voltage Supply

AVS arrived in EPR with PD 3.1 and came to SPR in PD 3.2. The PD specification says AVS can be adjusted over its advertised range but "otherwise is equivalent to a Fixed Supply": no programmable current limit. An AVS Request uses 25 mV units with the two lowest bits forced to zero, so the effective step is 100 mV.

The PD specification adds one rule for SPR AVS: the AVS object may only be offered if the 15 V fixed supply is also offered. Laptops and tools, not phones, are the main users of AVS, because they want a voltage close to a multi cell battery pack, not a constant current.

The whole power menu in one table

What does USB Type-C Authentication do, and how widely is it deployed?

What it is

The USB Type-C Authentication Specification lets a host or charger confirm, with cryptography, what kind of product is on the other end of the cable. Its introduction gives three example policies: a vendor accepts only certified PD chargers to avoid damage from substandard ones; a user sets a phone to charge only from certified PD products at a public terminal; and an organisation lets only storage devices signed by its IT team connect to company PCs. The USB-IF's January 2019 launch release said the specification "defines cryptographic-based authentication for USB Type-C chargers and devices", and that authentication can run over the USB data bus or over the PD channel.

In January 2019 the protocol itself moved into the USB Security Foundation Specification, and the Type-C Authentication document became the mapping of that protocol onto USB 2.0, USB 3.2 and USB PD.

How the exchange works

The Security Foundation specification targets a 128 bit security level. Its cryptographic choices are short:

There are three requests. GET_DIGESTS returns a SHA-256 digest of each stored certificate chain, so a charger that has met this phone before can compare against what it remembered. GET_CERTIFICATE reads a chain, in pieces, when the device is new. CHALLENGE sends a random 32 byte nonce; the responder signs a structure that includes the nonce, a hash of the chain, its own salt and a context hash, using the private key for that slot. Over PD these requests ride inside the Security_Request and Security_Response extended messages. The PD specification sums up the purpose of the challenge in one line: the port "challenges its Port Partner or the Cable Plug to detect replay attacks".

Two design choices stand out. Each product must have its own private key: the Security Foundation specification says one PD power supply cannot share a private key with another, "even if they are otherwise identical". And the specification warns that extracting even one key "could allow an attacker to clone products in unlimited volume", so it recommends tamper resistant key storage with protection against side channel and fault injection attacks. Periodic re-authentication is optional, to catch a product swapped after the first check.

What it does not do

Authentication answers "is this a genuine, certified product from this manufacturer". It does not decide what to do with the answer; policy is left to the product. The Security Foundation specification's own example is a PD sink that "may choose not to use the full advertised capabilities" of an unauthenticated charger. It does not encrypt the power or data link, does not inspect firmware behaviour after the check, and cannot help if a certified product's key has been extracted.

How widely is it deployed?

We could not find public figures. The USB-IF's 2019 release named no adopters and gave no numbers. None of the phone and laptop documentation we checked for this post describes a user setting for Type-C Authentication: Apple's accessory controls and Lockdown Mode are about locking and approval, and Google's USB Protection is about blocking data while locked. On Linux, the typec class exposes a cert_stat file for a partner or cable, but the kernel documentation describes it as the "Cert Stat VDO part of Discover Identity command result", which carries the USB-IF compliance ID (XID). That is a self reported identifier, not a cryptographic proof. The honest summary: the protocol is specified and a certificate program exists, but there is no public evidence of wide, user visible deployment in phones or laptops. If you are buying chargers for a fleet and authentication matters, ask the maker directly whether the product carries a USB-IF rooted certificate chain and how the key is stored.

Can a data connection happen over a "charge only" path, and what do OS USB restricted modes do?

What a USB-C cable actually carries

A USB-C cable carries VBUS and ground for power, CC for configuration and PD, VCONN for powering cable electronics, the USB 2.0 pair (D+ and D−), and in full featured cables the SuperSpeed pairs and sideband pins. The Type-C specification requires every full featured USB-C cable to be electronically marked; USB 2.0 Type-C cables need a marker only above 3 A.

A charge only cable or a data blocker leaves out the USB 2.0 and SuperSpeed pairs. That stops a USB data session: no mass storage, no media transfer, no keyboard enumeration over USB. It does not remove CC. A blocker that still passes CC lets PD negotiation work, which is exactly why some blockers keep fast charging and others do not.

What still crosses the CC wire

CC is a low speed channel, but it is a channel. After an Explicit Contract, the PD specification allows:

• Vendor_Defined messages, including Discover Identity, which returns vendor, product and certification information.
• Alternate mode discovery and entry on devices that support them.
• Firmware_Update_Request and Firmware_Update_Response extended messages, whose process the PD specification defers to a separate firmware update specification. Whether a phone or laptop accepts firmware over PD at all depends entirely on the device.
• Security_Request and Security_Response for authentication.

So "charge only" means "no USB data session", not "no communication". For most users that does not matter, since phones do not expose files over CC. For engineers it does: PD controller firmware sits below the operating system and parses messages from whatever is plugged in.

What the operating systems do

iPhone and iPad. Apple's support page says that by default you must unlock the device before it will connect to an accessory or computer, and that "your device will charge as usual when connected to a USB power adapter, even if you don't unlock it". Once connected while unlocked, the accessory stays connected after relock. Settings, Privacy & Security, Wired Accessories offers Always Ask, Ask for New Accessories, Automatically Allow When Unlocked (the default) and Always Allow; Lightning models have fewer options. Storage accessories always need an unlock. In Lockdown Mode, Apple's page says the device must be unlocked to connect to an accessory or computer.

Android with Advanced Protection. Google's USB Protection page says that while the screen is locked it "prevents establishment of a USB data connection", that charging continues, and that "in some cases, fast charging may not begin until the screen is unlocked". It is on Pixel 6 and later and turns on with Device protection. Google lists its limits: a connection made while unlocked stays active after locking, there is a few seconds' delay before data is cut after locking and unplugging, and an unlocked device is not protected.

Why consent prompts were not enough

The ChoiceJacking paper at USENIX Security 2025 showed that prompt based mitigations "assume that an attacker cannot inject input events" during setup. A malicious charger could answer its own prompt, reaching files on devices from eight vendors, two of them while locked. Our earlier post covers the vendor fixes. The lesson here: a charger is a computer with more than one way to talk.

What the FCC advises

The FCC's consumer page, last updated 27 April 2023, says that although juice jacking has been demonstrated as a proof of concept, "the FCC is not aware of any confirmed instances of it occurring". Its tips are to use AC outlets with your own charger and cables, carry a battery pack, consider a charging only cable from a trusted supplier, and choose "charge only" when a prompt offers it.

What does the EU common charger directive require, and from when?

Directive (EU) 2022/2380, signed in Strasbourg on 23 November 2022, amends the Radio Equipment Directive 2014/53/EU and adds Annex Ia. Article 2 makes the rules apply from 28 December 2024 for the categories in points 1.1 to 1.12 of Annex Ia and from 28 April 2026 for point 1.13, laptops. The Commission lists the first group as handheld mobile phones, tablets, digital cameras, headphones, headsets, portable speakers, handheld videogame consoles, e-readers, earbuds, keyboards, mice and portable navigation systems.

The technical requirements

For devices that charge by cable, Annex Ia Part I requires:

1. A USB Type-C receptacle as described in EN IEC 62680-1-3:2021, which must "remain accessible and operational at all times".
2. Charging with compliant cables, meaning cables that meet the same standard.
3. USB Power Delivery above the default. In so far as a device charges "at voltages higher than 5 Volts, currents higher than 3 Amperes or powers higher than 15 Watts", it must incorporate USB PD as described in EN IEC 62680-1-2:2021, and any additional charging protocol must allow the full functionality of USB PD.

Notice how cleanly this lines up with the CC section. 5 V at 3 A is 15 W, the ceiling of Type-C Current without any PD message. The directive leaves resistor-only charging alone and requires USB PD only for power above that ceiling.

Labels, unbundling and what comes next

Producers must offer the device without a charger and show a pictogram saying whether one is included. A label and the instructions must state the minimum and maximum power the device needs, with the text "USB PD fast charging" where it applies. The Commission estimates savings of at least 250 million euros a year and 980 tonnes less e-waste.

The recitals also mention that the USB-IF's updated PD specification supports up to 240 W, so higher power equipment can be considered later. The Commission's first review report on 30 June 2026 identified seven groups that could be added: smartwatches, fitness trackers, smart glasses, wristbands, AR and VR headsets, personal drones and video game controllers. By 28 December 2026 it must report on unbundling cables.

How do you inspect PD negotiation on Linux without special hardware?

Linux exposes USB-C ports through the typec class and PD capabilities through the usb_power_delivery class. The kernel documentation says the typec class exists to describe ports "to the user space in unified fashion", and that the driver registering them may be a Type-C or PD PHY driver, a PD controller driver, a Thunderbolt controller driver, or "a driver for firmware interface such as UCSI". UCSI, the USB Type-C Connector System Software Interface, is common on laptops: the embedded controller or PD chip runs the negotiation and reports results to the operating system. How much detail you see depends on that driver.

All commands below only read state. None of them change a role or a contract.

Step 1: find the ports

ls /sys/class/typec/
# typical output: port0  port0-partner  port0-cable  port1

ls /sys/class/usb_power_delivery/ 2>/dev/null
# typical output: pd0  pd1  pd2

If /sys/class/typec is empty, check the kernel log for the driver:

sudo dmesg | grep -i -E 'ucsi|typec|tcpm|tcpci' | tail -n 20
lsmod | grep -i -E 'ucsi|typec|tcpm'

Step 2: read roles, mode and revision

P=/sys/class/typec/port0
cat $P/data_role               # current role shown in brackets, e.g. [host] device
cat $P/power_role              # e.g. source [sink]
cat $P/power_operation_mode    # default, 1.5A, 3.0A or usb_power_delivery
cat $P/usb_typec_revision
cat $P/usb_power_delivery_revision
cat $P/orientation 2>/dev/null
cat $P-partner/usb_power_delivery_revision 2>/dev/null
cat $P-partner/supports_usb_power_delivery 2>/dev/null

power_operation_mode is the quickest answer to "did PD happen". The kernel ABI documentation lists exactly four values: default, 1.5A, 3.0A and usb_power_delivery. The first three are the Rp advertisements from the CC section. If you see 3.0A with a 100 W charger, no PD contract was made; try another cable or port.

Step 3: list what the charger advertised

The kernel documents that each PDO in a Source_Capabilities message becomes its own directory, named with its position, a colon and its type, such as 1:fixed_supply or 5:programmable_supply. Voltages are in millivolts and currents in milliamperes.

for pdo in /sys/class/usb_power_delivery/*/source-capabilities/*; do
  [ -d "$pdo" ] || continue
  printf '%s\n' "$pdo"
  for f in voltage minimum_voltage maximum_voltage maximum_current peak_current pps_power_limited; do
    [ -r "$pdo/$f" ] && printf '  %-18s %s\n' "$f" "$(cat "$pdo/$f")"
  done
done

A 65 W charger with PPS might produce something like this, which you can read against the trace in the negotiation section:

/sys/class/usb_power_delivery/pd1/source-capabilities/1:fixed_supply
  voltage            5000
  maximum_current    3000
/sys/class/usb_power_delivery/pd1/source-capabilities/4:fixed_supply
  voltage            20000
  maximum_current    3250
/sys/class/usb_power_delivery/pd1/source-capabilities/5:programmable_supply
  minimum_voltage    5000
  maximum_voltage    21000
  maximum_current    3250

The 1:fixed_supply directory also has flag files such as unconstrained_power, usb_communication_capable, dual_role_data and dual_role_power, which are the bits from the 5 V PDO. SPR AVS objects appear as spr_adjustable_voltage_supply with currents for the 9 to 15 V and 15 to 20 V bands. Which pdN belongs to the partner and which to your own port is linked from the typec port directory; ls -l /sys/class/typec/port0-partner/ shows the link on most systems.

Step 4: identify the cable

C=/sys/class/typec/port0-cable
cat $C/type 2>/dev/null          # undefined, active or passive
cat $C/plug_type 2>/dev/null
cat $C/usb_power_delivery_revision 2>/dev/null
for v in id_header cert_stat product product_type_vdo1; do
  printf '%-18s %s\n' "$v" "$(cat $C/identity/$v 2>/dev/null)"
done

The identity files hold the raw Discover Identity results and "will show 0 until Discover Identity command result becomes available", per the kernel documentation. product_type_vdo1 on a passive cable is the Cable VDO, the same object the source reads during EPR entry. Decoding the bits needs the PD specification's Cable VDO table, but even the raw value lets you compare two cables: if one cable gives your laptop usb_power_delivery at 20 V and 5 A and another stops at 3 A, the e-marker is the reason.

Step 5: watch attach and detach events

udevadm monitor --kernel --subsystem-match=typec --subsystem-match=usb_power_delivery

Plug in the charger and you will see the partner and its PD objects appear. Plug in through a charge only cable or blocker and compare: the typec events should still appear, because CC is connected, while lsusb in another terminal should show no new USB device from the far end.

What sysfs cannot show

On UCSI laptops the negotiation runs in firmware, so you see results, not individual messages or timing. For a full message trace you need an inline PD analyser; for most questions, Steps 2 to 4 are enough. On macOS, system_profiler SPPowerDataType shows the charger's wattage but not its individual offers.

Decision table: which mode, cable and setting for which job

Where Safeguard fits, honestly

The fit here is indirect, and it is worth being plain about it. Safeguard does not test chargers, verify Type-C certificates, manage phones, set accessory policy, scan PD controller firmware or generate hardware bills of materials. Those controls come from device makers, operating system vendors and device management tools. Safeguard models are single purpose security models for software; they do not do hardware or electrical analysis. Where Safeguard does connect is the software around this topic: the Linux kernel typec and UCSI drivers, the userspace tools you run to read them, and any internal tooling your team builds to collect charger and cable data across a fleet are ordinary software with open source dependencies. If you capture those components in a CycloneDX or SPDX file, safeguard scan --sbom <file> matches them against vulnerability databases and the platform shows which projects carry a given version.

That software angle is also why supply chain hygiene still belongs in a post about chargers. PD controller firmware, USB stacks and the scripts that inventory them all ship open source components, and the same rebuilt laptop that negotiates 240 W also pulls fresh dependencies the next time someone runs a build on it.

Common mistakes

• Assuming wattage on the label is what you get. A 100 W charger through a 3 A cable gives at most 60 W, because the source must see a 5 A e-marker before offering more than 3 A.
• Buying "240 W" cables without the EPR marking. EPR entry checks three e-marker fields: 50 V, 5 A and EPR Capable. A 5 A cable that is not EPR marked stops at 100 W.
• Reading 3.0A as success. On Linux, power_operation_mode showing 3.0A means no PD contract: the device is on Rp current only, 15 W at most.
• Treating PPS and AVS as the same thing. PPS has a programmable current limit and 20 mV steps; AVS has neither. A charger can support one without the other.
• Expecting PPS from 3.3 V. The current PD specification deprecates the 3.3 V minimum and requires 5 V.
• Believing a charge only cable stops all communication. It stops USB data. CC still carries PD messages, vendor defined messages and, on devices that support it, firmware update messages.
• Assuming Type-C Authentication is protecting you. It is optional, policy is up to each product, and we found no public evidence of user facing deployment in mainstream phones or laptops.
• Writing to typec sysfs files while exploring. Files such as power_role, data_role and vconn_source accept writes that request swaps. Read them with cat; do not echo values into them on a machine you depend on.
• Forgetting the EU rule is about the device, not the charger brick. In scope devices must accept USB PD above 15 W; the directive does not stop a maker adding its own protocol, as long as PD keeps full functionality.

FAQ

How does a USB-C charger know how much power to give?

At first it does not give more than 5 V. Resistors on the CC wire set a default of up to 3 A at 5 V. For more, the charger sends a Source_Capabilities message listing what it can do, the device sends a Request for one option, and the charger replies Accept and then PS_RDY once its output has changed.

What is the difference between USB PD 3.0, 3.1 and 3.2?

PD 3.0 (December 2015) added extended messages and later PPS. PD 3.1 (May 2021) added Extended Power Range: 28, 36 and 48 V fixed supplies up to 240 W, plus EPR AVS. PD 3.2 (October 2023) brought AVS to the standard power range, and its 2024 and 2026 versions deprecated old features and restructured the document.

Why does my 240 W charger only give 100 W?

Most often the cable. EPR needs a cable whose e-marker reports 50 V, 5 A and EPR Capable. The device must also support EPR and ask for it, and the two must already have a normal PD contract. If any check fails the charger stays in SPR, which tops out at 100 W.

What is an e-marked USB-C cable?

A cable with a small chip in the plug, powered by VCONN, that answers PD Discover Identity requests. It reports the cable's current rating, maximum voltage, speed and EPR capability. All full featured USB-C cables must have one, and any cable rated above 3 A must have one.

What is PPS charging?

Programmable Power Supply is a PD mode in which the device requests a voltage in 20 mV steps and a current limit in 50 mA steps. The charger holds the current at the limit by lowering voltage. Phones use it so the charger does most of the voltage conversion and less heat builds up inside the phone.

Is USB-C charger authentication turned on in my phone?

There is no setting for it on mainstream phones that we could find, and makers do not publish whether they use it. USB Type-C Authentication exists as a specification with a USB-IF certificate program since 2019, but it is optional, and we found no public figures on how many chargers or phones carry certificates.

Can a charge only cable be used to hack a phone?

A cable that truly has no USB data wires cannot open a USB data session, so the classic juice jacking routes do not apply. CC still carries Power Delivery messages, which are handled by the phone's PD controller. The FCC says it knows of no confirmed juice jacking cases; using your own charger in a wall outlet removes the question.

When did the EU require USB-C on phones and laptops?

Phones, tablets and ten other device types from 28 December 2024; laptops from 28 April 2026. Devices that charge above 5 V, 3 A or 15 W must also support USB Power Delivery.

How do I see what my USB-C charger offers on Linux?

Run cat /sys/class/typec/port0/power_operation_mode to see whether PD was used, then list the directories under /sys/class/usb_power_delivery/*/source-capabilities/. Each directory is one power option, with voltage in millivolts and current in milliamperes.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The local runner demo shows setting up Safeguard's runner on your own machine, approving it with its device code and then scanning from the terminal. That is the flow you would use to scan the scripts and tools that collect USB-C port and charger data on an engineering workstation, keeping the scan on that machine.

Click through it at your own pace, or open it full screen.

The CLI demo is a real session: you ask the Safeguard CLI to fix the lodash CVE in a repository, it reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same approve each step pattern applies when a vulnerable library turns up in an internal dashboard that reports charger and cable inventory.

Click through it at your own pace, or open it full screen.

The mobile app demo is a real Android session: you send work to a computer running the Safeguard CLI and approve each command on the phone with Allow once, Allow for turn or Deny. It fits the travel advice in this post, since the phone stays in control of what runs at home without being plugged into anything.

Click through it at your own pace, or open it full screen.

To try it on your own machines, download Safeguard and follow the CLI documentation.

Quick check

Sources

• USB-IF: USB Charger (USB Power Delivery)
• USB-IF document library: USB Power Delivery Specification Revision 3.2 Version 1.2
• USB-IF: USB Type-C Cable and Connector Specification
• USB-IF document library: USB Type-C Cable and Connector Specification Release 2.5
• USB-IF document library: USB Authentication Specification Rev 1.0 with ECN and Errata through January 7, 2019 (USB Type-C Authentication and USB Security Foundation specifications)
• USB-IF Launches USB Type-C Authentication Program (2 January 2019, press release as reprinted by Design and Reuse)
• Directive (EU) 2022/2380 of 23 November 2022 (Publications Office of the EU)
• Directive (EU) 2022/2380 on EUR-Lex
• European Commission: One common charging solution for all
• Linux kernel: USB Type-C connector class
• Linux kernel: ABI testing symbols (sysfs-class-typec and sysfs-class-usb_power_delivery)
• Linux kernel: USB Type-C bus
• Apple Support: Allow USB and other accessories to connect to your iPhone or iPad
• Apple Support: About Lockdown Mode
• Google: Protect your Android device from USB threats with Advanced Protection Mode
• FCC: What is 'Juice Jacking' and Tips to Avoid It (archived copy; page updated 27 April 2023)
• USENIX Security 2025: ChoiceJacking (Draschbacher, Maar, Oberhuber, Mangard)

Last reviewed: 24 October 2026.