Power over Ethernet Explained: 802.3af, at, bt, Classes and Security

Power over Ethernet (PoE) is the IEEE 802.3 method for sending DC power and data down the same twisted pair Ethernet cable, from a switch or injector (the PSE, Power Sourcing Equipment) to a camera, phone or access point (the PD, Powered Device). There are three generations: 802.3af (2003, 15.4 W at the port), 802.3at (2009, 30 W) and 802.3bt (2018, up to 90 W over all four pairs).

The power side is careful by design: a PSE only switches on after it has detected a valid signature and learned the device's power class. The security side is less careful. A PoE port is usually a network port in an exposed place, the device on it often runs outdated firmware, and anyone with switch management access can switch it off. This post covers both halves.

It extends our protocol by protocol series for layer 2. For the switching basics behind it, read how Ethernet switching works. For the discovery protocol that PoE uses to negotiate power, read LLDP and LLDP-MED explained. For what is inside the box that supplies the power, see how a network switch is made. For port authentication, see 802.1X and EAP.

Key takeaways

• PoE is defined in IEEE 802.3. The original 2 pair method (802.3af and 802.3at) lives in Clause 33; the 4 pair method from 802.3bt lives in Clause 145, according to the Ethernet Alliance certification program and the 802.3bt task force's own objectives document.
• 802.3af was approved by the IEEE SA Standards Board on 12 June 2003, 802.3at on 11 September 2009 and 802.3bt on 27 September 2018. All three are now listed as superseded because their text was folded into later consolidated editions of IEEE 802.3.
• The headline numbers: an 802.3af PSE supplies at least 15.4 W and the PD may draw up to 12.95 W; 802.3at raises that to 30 W and 25.5 W; 802.3bt Type 4 raises it to 90 W at the PSE and 71.3 W at the PD.
• The difference between the PSE figure and the PD figure is the power the standard budgets for loss in 100 metres of cable. That loss is heat, which is why cable category, bundle size and ambient temperature matter.
• A PSE goes through detection (is there a valid PoE device?), classification (how much power does it want?), power up, and then maintains power only while the device keeps drawing a minimum current. LLDP can then refine the allocation in 0.1 W steps.
• Passive PoE skips detection and classification. It puts a fixed voltage on the wires whether or not the device at the other end can take it.
• Security issues are mostly about the network port, not the electricity: exposed cabling outside the building, PoE devices with weak firmware, rogue devices on open ports, power cycling as a management action that can be abused, and power budgets that a misbehaving device can exhaust.

What is Power over Ethernet, and what do PSE and PD mean?

PoE solves an installation problem. A ceiling access point, a camera on a pole or a phone on a desk needs both a network connection and a power supply. Without PoE, an electrician has to run mains power to each location, or someone has to fit a local power adapter. With PoE, one Ethernet cable carries both, and the device can sit anywhere a data cable can reach, up to 100 metres from the switch.

The standard uses two roles.

PSE, Power Sourcing Equipment. The device that supplies power. The Linux kernel documentation for its PSE subsystem describes the PSE as equipment "delivering power along with data over Ethernet cables", usually "switches and hubs". There are two kinds:

• An endpoint PSE is built into the switch. The PoE ports on a PoE switch are endpoint PSEs.
• A midspan PSE sits between a non PoE switch and the device, and adds power to the cable as it passes through. A single port PoE injector is a midspan. The 802.3af task force's requirements document records the decision, in March 2000, that "The solution for DTE Powering shall support mid-span insertion of the power source."

PD, Powered Device. The device that receives power: an IP camera, a VoIP phone, a wireless access point, a thin client, a badge reader, an LED light fitting or a small single board computer with a PoE add-on board.

The interface where power enters or leaves the cable is the PI, the power interface, which in practice is the RJ45 jack. The IEEE standard measures power at the PI of each end, which is why you see two numbers for every class: what the PSE must deliver at its PI, and what the PD may draw at its PI.

A separate technology, PoDL (Power over Data Lines, Clause 104, 802.3bu), powers single pair Ethernet in vehicles and industrial controls. This post covers the four pair PoE used in buildings.

How the standards evolved

PoE arrived in three steps, each one an amendment to IEEE 802.3, the Ethernet standard. Each amendment was later folded into a consolidated edition of 802.3, which is why the IEEE Standards Association now lists all three as superseded rather than withdrawn. The technical content still applies; it just lives inside the main standard.

Timeline

Two dates in that table differ between IEEE sources. For the 802.3bt PAR, the task force page says it was approved on 18 March 2016 while the IEEE SA standard page says 12 May 2016. Both are IEEE pages. We give both rather than pick one.

802.3af (2003): the first standard

802.3af set the pattern every later version kept. The IEEE SA abstract describes "optionally powering a 10BASE-T, 100BASE-TX or 1000BASE-T DTE device" through the power interface, with the PSE "located at an end point or mid-span." The task force's working requirements, which are public on the IEEE 802.3 site, show how the decisions were made:

• Power uses two pairs, with "each wire in the pair at the same nominal potential," so power is a voltage between pairs rather than across one pair. That keeps the DC away from the data signal, which is carried as a difference between the two wires of each pair.
• Detection and power use the same set of pairs.
• The maximum voltage must stay within SELV (safety extra low voltage) limits.
• The maximum continuous current at the PD end is 350 mA.
• The PSE output voltage is between 44 and 57 V DC.
• Detection uses a resistor signature.

Multiply the minimum voltage by the maximum current and you get the famous number: 44 V times 0.35 A is 15.4 W. That is the power an 802.3af PSE must be able to supply on a port. The PD is allowed 12.95 W, and the difference is the cable loss budget, which the worked example later in this post explains.

802.3at (2009): PoE+

802.3at, marketed as PoE+, kept 2 pair power and the Clause 33 framework but added a higher power device type. The Ethernet Alliance's PD application note summarises it: 802.3at "upgraded and replaced 802.3af in order to add PDs that draw up to 25.5 watts" with PSEs that "furnish 30 watts on two of those wire pairs." The standard now names two types:

• Type 1: the original 802.3af power levels.
• Type 2: the new PoE+ levels, class 4, 30 W at the PSE and 25.5 W at the PD.

802.3at also added a second classification event so a Type 2 PSE and a Type 2 PD can recognise each other in hardware, and a link layer power negotiation using LLDP.

802.3bt (2018): 4 pair PoE

802.3bt is the big change. The IEEE SA abstract says the maximum PD power "is increased by this amendment ... by utilizing all four pairs in the specified structured wiring plant," and that "the power classification information exchanged during negotiation is extended to allow meaningful power management capability."

The objectives the study group adopted in 2013 set the shape of the project:

• support "a minimum of 49 Watts at the PD PI";
• support 10GBASE-T;
• define limits on pair to pair current imbalance, because current split unevenly across four pairs overheats one of them;
• keep 4 pair PDs working with older PSEs, and 4 pair PSEs working with older PDs;
• work over Category 5e or better cabling and channels with DC loop resistance of no more than 25 ohms;
• comply with limited power source and SELV requirements.

The final standard defines two new types:

• Type 3: classes 1 to 6, up to 60 W at the PSE. It can power on two or four pairs.
• Type 4: classes 7 and 8, up to 90 W at the PSE and 71.3 W at the PD, always four pairs.

The Ethernet Alliance's certification FAQ uses exactly this grouping when it lists which PDs need LLDP support: "Type 2 class 4 PDs, Type 3 class 1 6 PDs, and Type 4 class 7 8 PDs."

One source disagreement is worth flagging. The Linux kernel documentation summarises 802.3bt as "outlined in Clause 33" with Type 4 delivering "up to 100W." The 802.3bt objectives record a January 2017 motion to move 4 pair PoE "to its own clause," and the Ethernet Alliance says its Gen 2 test plan "is based on Clause 145 of IEEE 802.3, which includes the IEEE Std 802.3bt-2018 project." The Ethernet Alliance note also gives 90 W as the Type 4 PSE figure. We follow the IEEE task force and Ethernet Alliance: Clause 145 and 90 W. The kernel's own PSE header, interestingly, cites "IEEE 802.3-2022 Table 145-16" for its maximum per port power constant of 99,900 mW, so the kernel code itself points at Clause 145.

Power classes and types: what each delivers

Classification tells the PSE how much power to reserve. The table below combines the class figures published in the lldpd manual (classes 0 to 4), the class to power tables in Linux kernel PSE controller drivers (classes 5 to 8 at the PSE), and the Ethernet Alliance application note (Type 4 at the PD).

A few things this table hides:

• Class 0 is the default, not the smallest. A PD that does not present a class signature is treated as class 0 and gets the full 15.4 W reservation. That is wasteful on a big switch.
• Types are about the equipment, classes are about the request. A Type 3 PSE can power a class 3 PD over two pairs. A Type 4 PD can also run, at reduced power, from an older PSE.
• Driver tables round differently. One Linux PSE driver lists class 3 as 15,500 mW and another configures 15,000 mW plus a margin. Treat the IEEE figures as the contract and your datasheet as the implementation.
• Power demotion is normal. The Ethernet Alliance application note lists six demotion cases under 802.3bt, for example "a class 7 PD and a Class 8 PD could be demoted to class 3, to class 4, or to class 6." A compliant PD must notice that it was given less power than it asked for and stay within it. A PD that ignores demotion "may enter a rapid cycle of powering and overload shutdowns," which to a user looks like a faulty switch.

How detection and classification work

A PSE never puts full voltage onto a cable just because something is plugged in. It runs through a sequence that the Linux kernel exposes as the c33-pse-power-detection-status attribute, with values that come straight from IEEE 802.3: disabled, searching, delivering power, test, fault and other fault. RFC 3621's pethPsePortDetectionStatus object uses the same set.

Step 1: detection

The PSE applies a small, current limited probe voltage and measures the response. A valid PD presents a specific resistance signature across the pairs it will be powered on. The 802.3af task force chose this "resistor" discovery technique in November 2000. Anything else, an open circuit, a short, a normal network card with its termination, or a resistance outside the acceptance window, fails detection and the PSE stays in the searching state without applying power. The exact acceptance window and probe voltages are in Clause 33 of IEEE 802.3, which is available free of charge through the IEEE GET program.

Detection is the reason a standard PoE switch port is safe to plug a laptop into. It is also the thing passive PoE skips, which is why passive PoE is not safe to plug into arbitrary equipment.

Step 2: physical layer classification

Once a valid signature is found, the PSE applies a higher classification voltage and measures how much current the PD draws. The PD sets that current with a classification circuit, and the current band maps to a class number.

• 802.3af used one classification event. The PSE learns the PD's class; the PD learns nothing.
• 802.3at added a second event. A Type 2 PSE performs two classification events in a row, and the PD can detect that it saw two, which tells it the PSE is willing to deliver class 4 power. The Ethernet Alliance note puts it this way: 802.3at and 802.3bt "added classification mechanisms whereby a PD could determine the power that the PSE could provide."
• 802.3bt extended this to more events so classes 5 to 8 can be signalled, and added "mutual identification" (one of the 2013 objectives) so a 4 pair PSE and 4 pair PD can confirm each other before both pair sets are energised. It also defines single signature PDs (one detection and class signature for all four pairs) and dual signature PDs (each pair set detected and classified separately, useful when one device contains two independent loads). Wireshark's LLDP dissector carries exactly these values: "Type 3 single signature PD Device," "Type 3 dual signature PD Device," and the Type 4 equivalents.
• Autoclass, also from 802.3bt, lets a PD draw its maximum power for a short window right after power up so the PSE can measure the real figure, including cable loss, and allocate that instead of the class maximum. Wireshark's dissector has fields for PSE autoclass support, autoclass request and autoclass completed.

Step 3: power up and maintain power signature

The PSE applies full voltage with inrush current limited, then watches. As long as the PD keeps drawing a minimum current, the maintain power signature (MPS), the port stays on. If the PD is unplugged, MPS disappears and the PSE removes power. RFC 3621 counts these events in pethPsePortMPSAbsentCounter. The PSE also cuts power on overload or short circuit, which RFC 3621 counts in pethPsePortOverLoadCounter and pethPsePortShortCounter.

Step 4: LLDP power negotiation

Physical classification works in coarse steps. The Ethernet Alliance note estimates that classification lets a PSE assess demand "with approximate granularity of 15 watts," while "PoE LLDP allows the PSE to allocate power with granularity of 0.1 watt." Over a 48 port switch that difference decides how many devices you can power.

Two LLDP TLVs carry power information:

• IEEE 802.3 Power via MDI TLV. Defined by IEEE 802.3, originally with fields for port class (PSE or PD), whether power is supported and enabled, which pairs are used and the class. 802.3at added type, source, priority, requested power and allocated power. 802.3bt added extended fields for Type 3 and Type 4, dual signature class per pair set, power status and autoclass.
• LLDP-MED Extended Power via MDI TLV. Defined by the ANSI/TIA LLDP-MED specification for endpoints such as phones, with power type, source, priority and a power value. Our LLDP post covers LLDP-MED in detail.

The rules for who must speak LLDP are not symmetric. The Ethernet Alliance note says the standards "do not require PSEs to support PoE LLDP, however, they do require PDs operating with class 4 power or higher to support PoE LLDP," and that "PSEs that furnish more than 13 watts have the right to withhold PD requested power until the PD communicates its power demand via LLDP." The lldpd manual adds the LLDP-MED rules: a PD "shall never draw more than the maximum power advertised by PSE," and the PSE "shall not reduce power allocated to PD when this power is in use."

Alternative A, Alternative B, 2 pair, 4 pair and passive PoE

Which pairs carry the power

An RJ45 Ethernet cable has four twisted pairs on pins 1 and 2, 3 and 6, 4 and 5, and 7 and 8. 10BASE-T and 100BASE-TX use only pins 1, 2, 3 and 6 for data. 1000BASE-T and faster use all four pairs.

The 802.3af requirements document records the two options in May 2000: powering "via either sets of wire pairs (1 2, 3 6 and 4 5, 7 8)." In the standard these are:

• Alternative A: power on the data pairs 1 and 2 and 3 and 6. The voltage is applied to the centre taps of the data transformers, so each pair sits at a common DC potential and the data still flows as a differential signal on top.
• Alternative B: power on pins 4 and 5 and 7 and 8, the "spare" pairs in 10 and 100 Mb/s Ethernet.

The lldpd manual uses the plainer names signal ("the signal pairs only are in use") and spare ("the spare pairs only are in use") for the same choice. 802.3bt calls the two pair sets Mode A and Mode B.

A 2 pair PSE picks one alternative. An endpoint PSE may use either; the 802.3af requirements said a midspan should use 4 5 and 7 8 so it does not have to touch the data pairs. A compliant PD must accept power on either pair set and either polarity, which is why PDs have input bridges.

2 pair versus 4 pair

Running power on all four pairs instead of two halves the resistance of the path, because twice as many conductors share the current. For the same power, the current per conductor halves and the heat in each conductor drops to a quarter. That is the physics behind 802.3bt: you get more power to the PD without exceeding the current limit that keeps cables cool. It is also why 802.3bt needed objectives about pair to pair current imbalance. If one pair set has more resistance than the other, it carries less current and the other pair set carries more, and the hotter pair set limits the whole link.

Passive PoE

Passive PoE is not an IEEE standard. A passive injector or switch port puts a fixed DC voltage on the spare pairs all the time, with no detection, no classification and no maintain power signature. Some equipment for outdoor wireless links and small business networks still uses it.

The risks are practical:

• Plug a non PoE device into a passive port and the device receives whatever voltage the port applies, with nothing to check first.
• Plug a passive PoE device into a standard 802.3af or at switch and it will not power, because it has no detection signature.
• Passive voltages vary by product, so two passive devices are not interchangeable.

The Ethernet Alliance started its certification program partly for this reason. Its overview says that in August 2014 members "could see issues arising in the market as a result of the wide variety of products using the PoE name" and wanted to "distinguish PoE standards based products from proprietary PoE implementations." If a datasheet says "PoE" without naming 802.3af, at or bt and a class, ask which one it means.

Comparison table

How cable category, length and bundling affect voltage drop and heat

The gap between what a PSE sends and what a PD receives is resistance in the cable, and every watt lost in the cable becomes heat in the cable. Two worked examples make the published numbers make sense.

Worked example 1: where 12.95 W and 25.5 W come from

For 802.3af, the requirements give a minimum PSE voltage of 44 V and a maximum current of 350 mA.

• Power at the PSE: 44 V times 0.35 A = 15.4 W.
• The PD is allowed 12.95 W, so the standard budgets 15.4 minus 12.95 = 2.45 W of loss in the channel.
• Loss is current squared times resistance: 2.45 W divided by (0.35 A squared, which is 0.1225) = 20 ohms. That is the worst case channel resistance the arithmetic implies for Type 1.
• Voltage at the PD in that worst case: 44 V minus (0.35 A times 20 ohms) = 44 minus 7 = 37 V. Check: 37 V times 0.35 A = 12.95 W.

For 802.3at Type 2, 30 W at the PSE and 25.5 W at the PD leave 4.5 W of loss. If the current limit is 600 mA, the same arithmetic gives 4.5 divided by 0.36 = 12.5 ohms, and a PSE voltage of 30 divided by 0.6 = 50 V. The 12.5 ohms and 50 V figures are what the published wattages imply; the exact limits are in Clause 33. The 600 mA figure appears in the IEEE 802.3bt field deployment slides as the per pair current used in the TSB-184 heating analysis.

So the "PSE watts" number is not marketing rounding. It is the PD budget plus the worst case loss in a 100 metre channel.

Worked example 2: a real 100 metre run, 2 pair versus 4 pair

Take 100 m of 24 AWG solid copper horizontal cable. A typical wire table value for 24 AWG copper is about 0.084 ohms per metre at 20 degrees Celsius, so one 100 m conductor is about 8.4 ohms. (Your cable's datasheet gives the exact figure; this is an illustrative value.)

2 pair power at 600 mA. Current goes out on one pair, whose two conductors are in parallel (8.4 / 2 = 4.2 ohms), and returns on another pair (another 4.2 ohms). Path resistance is about 8.4 ohms.

• Voltage drop: 0.6 A times 8.4 ohms = 5.0 V.
• Loss: 0.6 squared times 8.4 = 0.36 times 8.4 = 3.0 W.

Now warm the cable up. Copper resistance rises by roughly 0.39 percent per degree Celsius. At 60 degrees, 40 degrees above the reference, resistance is about 8.4 times 1.16 = 9.7 ohms, and the loss at 600 mA rises to 0.36 times 9.7 = 3.5 W. Add patch cords, which are often thinner stranded conductors, and connectors, and you can see why the standard budgets 4.5 W.

4 pair power at 90 W. Assume, for illustration, the PSE delivers 90 W at 52 V. Total current is 90 / 52 = 1.73 A. With all four pairs in use, the current goes out on two pairs and returns on two pairs, so each direction has four conductors in parallel (8.4 / 4 = 2.1 ohms) and the path resistance is 4.2 ohms.

• Each pair carries half the total current: 0.87 A.
• Loss: 1.73 squared times 4.2 = 3.0 times 4.2 = 12.6 W.
• Voltage drop: 1.73 times 4.2 = 7.3 V.

The 802.3bt allowance between 90 W at the PSE and 71.3 W at the PD is 18.7 W, so the warm cable, patch cords and connectors still fit.

If you tried to push 1.73 A down only two pairs, the path resistance would double to 8.4 ohms and the loss would be about 25 W. That is the main reason 802.3bt uses all four pairs.

Bundling and heat: what TSB-184 says

A single cable dissipating 3 to 12 W over 100 metres warms only slightly. A bundle of 100 cables in a tray, all carrying PoE, warms much more, because the cables in the middle cannot shed heat. The IEEE 802.3bt cable heating ad hoc reviewed the TIA guidance on this in 2014. The slides presented to the task force summarise TIA TSB-184:

• Cables in commercial premises generally have a temperature rating of 60 degrees Celsius.
• TSB-184 specifies 15 degrees Celsius as the maximum allowed temperature rise above ambient, which implies a maximum ambient of 45 degrees Celsius.
• For a 100 cable bundle with power on all four pairs, the maximum current per pair at 45 degrees ambient is 735 mA for Category 5e, 805 mA for Category 6 and 865 mA for Category 6A. At 25 degrees ambient the limits rise to about 1,123, 1,230 and 1,321 mA.
• Delivering 600 mA on two pairs of every cable in a 100 cable Category 5e bundle raises temperature by 5 degrees Celsius.

Compare those limits with worked example 2. A Type 4 PD at full power puts about 0.87 A on each pair. That is above the TSB-184 limit for a large Category 5e or Category 6 bundle at 45 degrees ambient, and close to the Category 6A limit. In practice this means:

• Use Category 6A for high power 802.3bt runs, because thicker conductors have lower resistance and the cable dissipates heat better.
• Avoid large tight bundles of high power PoE cables, especially in warm ceiling voids.
• Remember that higher temperature raises resistance, which raises loss, which raises temperature. The standard's margins assume the installation stays within the cabling guidance.

The ANSI/TIA document itself is sold, so we cite the IEEE task force slides that summarise it. Check the current TSB-184 revision before you design a large high power installation.

How to plan a PoE budget for a switch

A PoE switch has two limits: the per port maximum (set by the PSE type) and the total PoE budget (set by its power supply). The total is almost always lower than the number of ports times the per port maximum.

How switches allocate

There are two common allocation methods, and the Linux kernel's PSE core names them in its budget evaluation strategies:

• Static, "based on the power requested during PD classification." The switch reserves the class maximum for each port. Safe, simple and wasteful.
• Dynamic, "based on the current consumption per ports compared to the total power budget." The switch measures what each port actually draws. Efficient, but a sudden load increase (a camera's heater switching on in winter) can push the switch over budget.

LLDP allocation sits between them: the switch reserves what the PD asks for over LLDP, with 0.1 W resolution.

When the switch runs out of budget, it sheds ports by priority. RFC 3621 defines three port priorities: critical, high and low. The Linux ethtool manual describes the same behaviour for its numeric priority: "When a single domain exceeds its budget, ports in that domain are powered up/down by priority (highest first for power up; lowest shed first)."

Worked example 3: a 24 port switch with cameras and access points

Suppose a 24 port switch with a total PoE budget of 370 W (an illustrative figure; check your datasheet). You want to connect:

• 12 fixed cameras, class 3 (802.3af), each drawing about 7 W in practice;
• 6 Wi-Fi access points, class 4 (802.3at), each requesting 21 W at the PD over LLDP;
• 2 outdoor pan tilt zoom cameras with heaters, class 6 (802.3bt Type 3), each requesting 48 W at the PD over LLDP.

Static allocation by class.

484.8 W against a 370 W budget is 114.8 W short. On static allocation, the last devices to power up would be refused.

LLDP based allocation. The PSE has to reserve the PD's request plus the cable loss. A simple planning margin is the class 4 ratio from worked example 1: 30 / 25.5 = 1.18. (This is our planning rule of thumb, not a figure from the standard.)

359.6 W fits in 370 W, with about 10 W of headroom. That headroom is thin. Three decisions follow:

1. Set priorities. Mark the cameras that cover entrances and the access points that carry voice as critical or high. Leave lobby displays and spare ports low. When the budget runs out, the switch drops the least important devices first rather than whichever powered up last.
2. Keep 10 to 20 percent spare. Heaters, infrared illuminators at night and access point radio upgrades all raise draw. A budget at 97 percent of capacity will shed ports on the coldest night of the year.
3. Put the switch on a UPS sized for the PoE load, not just the switch. If the switch loses power, every camera and access point goes dark with it. Our homelab UPS sizing guide walks through the arithmetic; add the PoE budget you actually allocate to the switch's own draw. lldpd's LLDP-MED options even let a PSE signal that it is on backup power so PDs can conserve: the backup source value means "the power source is the backup power source, or a power conservation mode is requested (the PSE may be running on UPS for example)."

Security issues with PoE

PoE does not create a new class of network attack. It puts live network ports in ceilings, on outside walls and on poles, connected to devices few people patch. Here are the issues and the fix for each.

PoE devices on untrusted ports

Outdoor cameras, door entry panels and badge readers are designed to be mounted where the public can reach them. Behind each one is a cable that runs back to a switch port inside the building. Unplug the camera, plug a laptop into the cable and, unless the port is protected, the laptop is on whatever VLAN the camera was on.

Fixes:

• Put PoE endpoints on their own VLANs, with firewall rules that allow only the traffic each device class needs (a camera talks to the video recorder, not to the internet or the finance server).
• Use 802.1X where the device supports it, and MAC Authentication Bypass with a dedicated, restricted VLAN where it does not. MAB is weak on its own because MAC addresses are visible on the device label and on the wire, so pair it with tight VLAN rules. Our 802.1X and EAP post covers the setup.
• Where the switch and devices support it, add MACsec on links that pass through spaces you do not control.
• Alert when a camera port drops and comes back with a different MAC address.

Rogue devices and fake power requests

Detection makes sure there is a PoE load before power is applied. It does not authenticate anything. A device can present any valid class signature and, if it speaks LLDP, request any power it likes. LLDP has no authentication, as our LLDP post explains.

The conceptual risk is a budget denial of service: a device that requests or draws much more power than it needs can push a switch over its budget, and the switch then sheds other ports by priority. The defence is mostly configuration:

• Set per port power limits to what each device class needs. The Linux kernel exposes this as the configurable PSE power limit (c33-pse-avail-pw-limit in milliwatts), and most managed switches have an equivalent per port maximum.
• Set priorities so critical devices are never the ones shed.
• Disable PoE on ports that do not need it. An unused port in a meeting room should not be both live on the network and able to power a device.
• Watch RFC 3621 counters such as pethPsePortPowerDeniedCounter and pethPsePortOverLoadCounter, and the switch's PoE event log. A port that suddenly reports a different class is worth a look.

Power cycling as a management action

Turning PoE off and on for a port is the standard way to reboot a hung camera or access point remotely. It is useful, and it is a power that anyone with switch management access holds over every PoE device. A compromised switch management account, a misconfigured automation script or a mistyped port range can switch off every camera in a building at once, which is exactly what someone planning a physical intrusion would want.

Treat PoE control as a privileged action:

• Put switch management on a separate management network, with role based access so helpdesk accounts can view PoE status but not change it.
• Log and alert on PoE disable events, especially on camera and access control ports.
• In automation, scope power cycling to one port at a time, with a check that the port actually has the device you expect (an LLDP neighbour or a known MAC address) before the action runs.
• Review scheduled PoE (some switches can switch ports off at night to save power) so a schedule cannot turn off security cameras.

Physical access to camera cabling

NIST SP 800-53 has two physical controls that read as if they were written for PoE. PE-4, access control for transmission, asks organisations to control physical access to distribution and transmission lines, and lists "disconnected or locked spare jacks, locked wiring closets, protection of cabling by conduit or cable trays, and wiretapping sensors." PE-9, power equipment and cabling, asks organisations to protect power equipment and power cabling "from damage and destruction." A PoE cable is both.

For outdoor and public cameras:

• Run the cable in conduit or inside the mounting where it cannot be reached without tools.
• Use tamper alarms on the camera housing if available, and alert on the video recorder when a stream drops.
• Lock the communications rooms and cabinets where midspans and switches sit.
• Disconnect or disable spare jacks. SC-41 in the same NIST catalogue, port and I/O device access, asks organisations to disable or remove unneeded connection ports; physically disabling them "is the stronger action."

The devices themselves

Most practical PoE risk is the firmware on the powered devices and on the switch. IP cameras, phones and access points run embedded operating systems built from open source components, ship with web interfaces and remote management protocols, and are often left on the firmware they were installed with. The PSE side runs software too. The Linux driver for one PSE controller family checks the controller's firmware version and logs "Too old firmware version. Please update it," because the PSE controller is a microcontroller with its own firmware.

Keep an inventory of PoE devices with model and firmware version, follow each maker's security advisories, and plan firmware updates as you would for servers.

Step by step: read PoE status and LLDP power on a switch and from Linux

The steps below use tools that work on any vendor's equipment: SNMP with the standard MIB, lldpd on Linux, and ethtool for Linux systems that expose a PSE controller. Command syntax on your switch's own command line will differ; look for its PoE status, per port power and LLDP neighbour commands.

Step 1: read PoE status from a managed switch over SNMP

RFC 3621 defines the Power Ethernet MIB under mib-2 105, which is OID 1.3.6.1.2.1.105. Use SNMPv3 with authentication and privacy, never community strings on a network you do not fully control.

# Walk the whole Power Ethernet MIB on a switch (read only account, SNMPv3 authPriv)
snmpwalk -v3 -l authPriv -u poe-monitor -a SHA -A 'AUTH_PASSPHRASE' \
  -x AES -X 'PRIV_PASSPHRASE' switch1.example.net 1.3.6.1.2.1.105

# With the MIB installed, ask for named objects
snmpwalk -v3 -l authPriv -u poe-monitor -a SHA -A 'AUTH_PASSPHRASE' \
  -x AES -X 'PRIV_PASSPHRASE' switch1.example.net POWER-ETHERNET-MIB::pethPsePortDetectionStatus
snmpget  -v3 -l authPriv -u poe-monitor -a SHA -A 'AUTH_PASSPHRASE' \
  -x AES -X 'PRIV_PASSPHRASE' switch1.example.net \
  POWER-ETHERNET-MIB::pethMainPsePower.1 POWER-ETHERNET-MIB::pethMainPseConsumptionPower.1

What to read:

• pethPsePortDetectionStatus per port: disabled(1), searching(2), deliveringPower(3), fault(4), test(5), otherFault(6).
• pethPsePortPowerClassifications: the class the port detected.
• pethPsePortPowerPriority: critical(1), high(2), low(3).
• pethMainPsePower: total PSE power in watts, and pethMainPseConsumptionPower: what is being consumed now, also in watts. Their ratio is your budget headroom.
• The counters pethPsePortMPSAbsentCounter, pethPsePortInvalidSignatureCounter, pethPsePortPowerDeniedCounter, pethPsePortOverLoadCounter and pethPsePortShortCounter.

A rising invalid signature counter on a port can mean a non PoE device or a faulty cable. A rising power denied counter means the budget is exhausted. A rising MPS absent counter can mean a device is being unplugged and replugged.

Step 2: install lldpd on a Linux host

On a Linux machine connected to the switch (a PoE powered single board computer is a good example, because it is itself a PD):

# Debian or Ubuntu
sudo apt install lldpd
# Fedora or RHEL family
sudo dnf install lldpd

sudo systemctl enable --now lldpd

Step 3: see what the switch advertises about power

# All neighbours with full TLV detail
sudo lldpcli show neighbors details

# One interface only
sudo lldpcli show neighbors ports eth0 details

If the switch sends the IEEE 802.3 Power via MDI TLV or the LLDP-MED Extended Power TLV, the output includes the port's power role (PSE), whether power is supported and enabled, the pairs in use (signal or spare), the class, and for 802.3at and later the type, source, priority, requested and allocated power. The allocated value is what the switch has reserved for you.

Step 4: advertise power needs from a Linux PD

If the Linux host is itself powered by PoE, it can tell the switch what it needs. The lldpd manual gives these forms:

# 802.3at style: a Type 1 class 3 PD on the spare pairs, requesting 10 W with 15 W allocated
sudo lldpcli configure dot3 power pd supported enabled powerpairs spare \
  class class-3 type 1 source pse priority low requested 10000 allocated 15000

# LLDP-MED style: request 5 W from the PSE at high priority
sudo lldpcli configure med power pd source pse priority high value 5000

Values are in milliwatts. The manual warns that lldpd does "no check" on these values, so a PD that claims more than its hardware class or more than the PSE offers is breaking the rules the manual lists. Keep the two TLVs consistent if you send both, and make the configuration persistent in /etc/lldpd.d/ so it survives a reboot.

Step 5: read PSE status with ethtool on Linux based switches and boards

Linux has a PSE subsystem for systems where Linux itself controls a PSE chip: embedded switches, routers and development boards with PoE ports. On those systems ethtool reports and controls the PSE. On an ordinary PC network card, the command reports that PSE is not supported.

# Show PSE state for one port
ethtool --show-pse lan1

# Same in JSON, for scripts
ethtool --json --show-pse lan1

The ethtool manual lists the fields:

• c33-pse-admin-state: enabled or disabled.
• c33-pse-power-detection-status: disabled, searching, delivering power, test, fault or other fault.
• c33-pse-extended-state and c33-pse-extended-substate: more detail when something is wrong.
• c33-pse-power-class: the class negotiated with the PD.
• c33-pse-actual-power: power drawn now, "reported in mW."
• c33-pse-available-power-limit and c33-pse-power-limit-ranges: the configured limit and the allowed range, in mW.

Step 6: set limits and priorities, and power cycle safely

Warning: disabling PSE on a port cuts power to whatever is plugged into it. If that is a camera, it stops recording. If it is an access point, every client on it disconnects. If it is a door controller, check what the door does without power before you continue.

Check first that you have the right port and the right device:

# 1. Confirm which device is on the port you are about to touch
sudo lldpcli show neighbors ports lan1 summary
ethtool --show-pse lan1

# 2. Only if the neighbour and power class match what you expect, continue

Then make the change:

# Cap the port at 15.4 W (class 3 equivalent), in milliwatts
sudo ethtool --set-pse lan1 c33-pse-avail-pw-limit 15400

# Set a shedding priority (range 0 to the priority-max shown by --show-pse)
sudo ethtool --set-pse lan1 prio 1

# Power cycle the device on lan1 (see the warning above)
sudo ethtool --set-pse lan1 c33-pse-admin-control disable
sleep 5
sudo ethtool --set-pse lan1 c33-pse-admin-control enable

On a managed switch, the same actions are per port PoE limit, priority and PoE disable or enable commands, and they should require a privileged role.

Step 7: watch LLDP power frames on the wire

To see what is actually exchanged, capture LLDP frames by their EtherType:

sudo tcpdump -i eth0 -nn -v ether proto 0x88cc

Wireshark decodes the IEEE 802.3 Power via MDI TLV, including the 802.3bt single and dual signature values and autoclass bits, which settles disputes between what a device requested and what the switch allocated.

Certification: how to tell standard PoE from look alikes

The Ethernet Alliance runs a PoE certification program with two test plans: Gen 1 "is based on Clause 33 of IEEE 802.3," covering 802.3af and 802.3at, and Gen 2 "is based on Clause 145," covering 802.3bt. Certified products appear on a public registry and may carry a class logo. The Alliance's own pages date the program differently: the overview says work began after August 2014, the infographic page says it "launched in 2017," and an older FAQ refers to a "formal launch of the program in November 2019." Certification covers interoperability with the IEEE power behaviour, not the security of a device's firmware or web interface.

Common mistakes

• Assuming "PoE" means 802.3af, at or bt. Passive PoE devices and injectors use the same name. Check the datasheet for the IEEE standard and class.
• Adding up port maximums instead of checking the total budget. A 48 port switch may support 30 W per port and still have a total budget far below 48 times 30 W.
• Leaving every port on static class allocation. Class 0 and unclassified devices reserve 15.4 W each. Use LLDP allocation where both sides support it.
• No port priorities. When the budget is exceeded, an unprioritised switch sheds by port number or power up order, which may be your entrance camera.
• Ignoring heat in large bundles. High power 802.3bt over Category 5e in a large bundle in a warm ceiling can exceed TSB-184 current guidance.
• Putting cameras on the user VLAN. A camera port is a network port on an outside wall. Segment it and authenticate it.
• Letting everyone with switch access power cycle ports. PoE disable is a privileged action that can blind every camera.
• Never updating PoE device firmware. Cameras, phones and access points are computers with network services and need patching like any other.

FAQ

What is the difference between PoE, PoE+ and PoE++?

PoE is 802.3af (2003), up to 15.4 W at the switch port and 12.95 W at the device. PoE+ is 802.3at (2009), up to 30 W and 25.5 W. PoE++ is the market name for 802.3bt (2018): Type 3 up to 60 W and Type 4 up to 90 W at the port, with up to 71.3 W at the device. 802.3bt uses all four pairs at higher classes.

Can PoE damage a device that does not support it?

Standard PoE should not. A PSE only applies full power after detecting a valid PoE signature, and an ordinary network card does not present one. Passive PoE can, because it applies voltage without checking what is connected.

What cable do I need for PoE?

The 802.3bt objectives call for Category 5e or better. For high power 802.3bt and large bundles, Category 6A has lower resistance and higher current limits in the TSB-184 guidance (865 mA per pair at 45 degrees Celsius ambient in a 100 cable bundle, against 735 mA for Category 5e).

How do I know how much power my PoE switch can supply?

Look for the total PoE budget on the datasheet, not the per port maximum. On a running switch, read pethMainPsePower and pethMainPseConsumptionPower from the Power Ethernet MIB over SNMP, or the switch's own PoE status command.

Do PoE devices need LLDP?

PDs that need class 4 power or higher must support LLDP power negotiation, according to the Ethernet Alliance's summary of the standards, and PSEs may withhold full power until they hear it. PSEs are not required to support LLDP, but many do because it lets them allocate in 0.1 W steps.

Is PoE a security risk?

PoE itself is low voltage and has a careful power up sequence. The security risk is that PoE puts network ports in exposed places and powers devices with long lived firmware. Segment PoE devices, authenticate ports with 802.1X where possible, protect cabling physically, and restrict who can power cycle ports.

Can someone plug a laptop into a security camera cable?

Yes, if the port is not protected. The laptop will not receive PoE power (it has no PD signature), but it will get a network link on the camera's VLAN. Use 802.1X or restricted MAB, dedicated VLANs with tight rules, and alerts on link changes for camera ports.

What are Alternative A and Alternative B?

They are the two ways to put power on a 2 pair PoE link. Alternative A uses the data pairs on pins 1 and 2 and 3 and 6. Alternative B uses pins 4 and 5 and 7 and 8. A compliant PD accepts either. 802.3bt calls the two pair sets Mode A and Mode B and can use both at once.

Where Safeguard fits

Safeguard does not monitor PoE budgets, configure switches, manage cameras or scan device firmware, and it is not a network access control product. The connection is narrower. The software around PoE is built from open source: the Linux kernel's PSE drivers and ethtool on embedded switches, lldpd and SNMP libraries on monitoring hosts, and the Python and Go scripts and container images your team writes to collect PoE status and automate port changes. Safeguard scans those repositories, container images and SBOM files, matches their components against vulnerability databases, ranks findings with reachability analysis, and can open pull requests that move a vulnerable dependency to a fixed version, with remediation switched off by default until you turn it on.

The firmware on cameras, phones and access points still has to come from their makers. What Safeguard can keep patched is the software you build and run around them.

PoE devices and switches ship open source components in their operating systems and management stacks, and the tools you write to monitor and control PoE pull open source dependencies every time they are rebuilt. Keeping that part of the stack patched is ordinary software supply chain work, and these are the options Safeguard offers for it.

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

These demos show dependency, SBOM and remediation workflows, not PoE monitoring or switch management. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the container image for a PoE monitoring collector or an SNMP polling service your team builds, the same scan lists the packages and versions inside it and their known vulnerabilities.

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

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a vulnerable dependency in a Python or Go network automation repository that reads PoE status or power cycles ports.

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

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version, such as an SNMP or LLDP parsing library used by your network tooling, and get the answer from your own scan data rather than from memory.

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

Quick check

Sources

• IEEE 802.3af DTE Power via MDI Task Force
• IEEE P802.3af requirements document
• IEEE P802.3af objectives
• IEEE P802.3at DTE Power Enhancements Task Force
• IEEE P802.3bt DTE Power via MDI over 4 Pair Task Force
• IEEE P802.3bt objectives
• IEEE P802.3bt cable heating ad hoc archive
• IEEE P802.3bt guidelines for field deployment (TSB-184 review)
• IEEE SA: IEEE 802.3af-2003
• IEEE SA: IEEE 802.3at-2009
• IEEE SA: IEEE 802.3bt-2018
• IEEE SA: IEEE 802.3-2022
• IEEE SA: P802.3 revision project
• Ethernet Alliance: PoE Certification
• Ethernet Alliance: PoE Certification program overview
• Ethernet Alliance: PoE infographic
• Ethernet Alliance: PoE certification FAQ, Gen 1 and Gen 2
• Ethernet Alliance: PD design for conformance and interoperability application note
• Linux kernel documentation: Power Sourcing Equipment (PSE) in IEEE 802.3
• Linux kernel source: include/linux/pse-pd/pse.h
• Linux kernel source: drivers/net/pse-pd/pse_core.c
• Linux kernel source: drivers/net/pse-pd/tps23881.c
• Linux kernel source: drivers/net/pse-pd/pd692x0.c
• ethtool(8) manual page
• lldpd usage and manual pages
• lldpd source: lldpcli.8 manual page
• Wireshark source: LLDP dissector (packet-lldp.c)
• IETF RFC 3621: Power Ethernet MIB
• NIST SP 800-53 Rev. 5: Security and Privacy Controls (PE-4, PE-9, SC-41)

Last reviewed: 24 October 2026. IEEE 802.3 is being revised under a PAR approved in December 2025, and switch and driver behaviour changes between releases; check the current standard, the TSB-184 revision and your equipment's documentation before you design a high power installation.