Network Cards Explained: Ethernet to 800 GbE, MAC Privacy, SmartNICs

A network card (NIC) is the part of a computer that turns frames into signals on a wire, fibre or radio, and it has grown from a simple 10 Mb/s transceiver into a programmable computer of its own. IEEE approved 800 Gb/s Ethernet in February 2024 and 1.6 Tb/s is in ballot. Along the way the NIC picked up a permanent identity (the MAC address), offload engines, virtual functions and, on servers, management paths that work while the host is off. Each of those is a privacy, isolation or patching question you can check with a few commands.

Key takeaways

• Ethernet grew from 1 Gb/s (802.3z, July 1998) to 800 Gb/s (802.3df, approved 16 February 2024). The 1.6 Tb/s amendment, 802.3dj, passed its initial Standards Association ballot on 26 March 2026 and is still being finalised.
• A MAC address is a 48 bit identifier whose prefix usually comes from an IEEE assigned block, so the vendor can often be read from it.
• On Wi-Fi, Android (since 10) and Apple (since iOS 14 and macOS Sequoia 15) randomize by default; Windows offers global and per network toggles. Wired Ethernet usually keeps the burned in address.
• Offloads (checksum, TSO, LRO, RSS) save CPU but change what captures show and can break forwarding. Check them with ethtool -k.
• SR-IOV isolation depends on the IOMMU, the physical function driver and settings like spoof checking.
• SmartNICs and DPUs run their own firmware, operating system and management controller. Inventory and patch them like computers.
• Exposed out of band management is dangerous: CVE-2017-5689 in Intel's manageability firmware scored 9.8 and is on CISA's Known Exploited Vulnerabilities list.

A short history of the network card

Early Ethernet was a shared medium. Every station on a segment of coax heard every frame and picked out the ones addressed to it, which is exactly why each card needed a unique hardware address. The early 10 Mb/s variants ran on thick coax (10BASE5), then thin coax, then twisted pair (10BASE-T), and Fast Ethernet raised the rate to 100 Mb/s. The Ethernet Alliance puts the technology's history at more than 50 years. From gigabit onward, each speed step has an IEEE 802.3 task force page recording its approval date, so the table starts there.

Dated timeline of Ethernet milestones

As of the IEEE 802.3 home page's update on 15 October 2026, 802.3dj (200 Gb/s, 400 Gb/s, 800 Gb/s and 1.6 Tb/s) is still listed as an active task force. Other active projects include 802.3dv (400 Gb/s per lane signaling), 802.3ds (200 Gb/s per wavelength multimode fibre PHYs), 802.3dt (Ethernet metadata services) and automotive work. If you read that "1.6T Ethernet is a finished standard", check the date: the ballot record we found says it was still resolving comments in 2026.

Speed and use comparison

The Ethernet Alliance's 2026 roadmap describes the same frontier: AI interconnects from 100G to 800G with 1.6 Tb/s emerging, and enterprise moves to 2.5G, 5G and 10GBASE-T. For what happens after a frame leaves the card, see how Ethernet switching works; for why 800G links exist, see scale up versus scale out AI networks.

Where Wi-Fi adapters fit

A Wi-Fi adapter is a NIC too, with a MAC address from the same IEEE address space, its own firmware and a driver. Two differences matter. It broadcasts: while searching for networks it sends probe requests anyone nearby can hear, so its address leaks before you connect. And much of its logic lives in firmware plus user space software such as wpa_supplicant on Linux. That is why the privacy features below are mostly Wi-Fi features.

What is a MAC address, and how does the IEEE OUI registry work?

A MAC address is the link layer address on every Ethernet and Wi-Fi frame. The common form, EUI-48, is 48 bits written as six hex pairs, for example 3c:22:fb:12:34:56. The IEEE Registration Authority hands out the blocks that keep those addresses unique:

• MA-L (MAC Address Block Large) includes an OUI and large blocks of EUI-48 and EUI-64 values. The OUI is the 24 bit prefix you see at the start of most addresses.
• MA-M (MAC Address Block Medium) gives medium sized blocks for organisations that need fewer addresses.
• MA-S (MAC Address Block Small) includes an OUI-36 and small blocks.
• CID (Company ID) is a 24 bit identifier that cannot be used to generate EUI-48 or EUI-64 values, for uses where unique MAC addresses are not needed.

The IEEE says the same blocks can be used as MAC addresses, Bluetooth device addresses, Ethernet addresses or object identifiers. It publishes the assignments as public listings and downloadable CSV files, which is how network tools turn the first half of an address into a vendor name.

The two bits that matter

Two bits in the first byte of a MAC address carry meaning:

• The lowest bit is the individual or group bit. Zero means unicast, one means multicast.
• The second lowest bit is the universal or local bit. Zero means the address came from an IEEE assigned block. One means it was assigned locally, by software or an administrator.

Android's documentation states that a randomized MAC should have the locally generated bit set to 1 and the multicast bit set to 0. NetworkManager's documentation says the same in its own words: when it generates a random or stable address it creates "a locally-administered, unicast MAC address". In practice, if the second hex digit of an address is 2, 6, A or E, you are almost certainly looking at a locally administered address, very often a randomized one. That is also why vendor lookups fail on those addresses: there is no OUI to look up.

Why it matters for privacy

A burned in address is a stable identifier. Anything that can see your frames, from a café's access point to a retail analytics sensor listening for probe requests, can recognise the same device across days and locations. Microsoft's support page says it plainly: when a device is not connected it broadcasts its hardware address while searching for networks, and some places could use that to track your movement. Randomization exists to break that link.

A related question is whether the card itself stores what you did online. It does not work that way, and we cover the details in does your network card keep your browsing history.

How does MAC randomization work on each operating system?

Every major platform now randomizes Wi-Fi addresses, but the defaults, the rotation rules and the controls differ. The table summarises what each vendor's own documentation says.

Android

Android's source documentation gives the clearest history. From Android 8.0, devices use randomized addresses when probing for new networks while not associated. Android 9 added connection time randomization as a developer option, off by default. In Android 10, MAC randomization is enabled by default for client mode, SoftAp and Wi-Fi Direct. The page describes randomized addresses as generated per SSID and persistent, so forgetting and rejoining the same network gets the same random address. That is deliberate: networks that use the address for captive portal sessions keep working, while two different networks cannot link you.

Apple platforms

Apple's support article, "Use private Wi-Fi addresses on Apple devices", says devices use a different Wi-Fi address for each network, and that it is on by default. Requirements are iOS 14, iPadOS 14, watchOS 7, visionOS, and macOS Sequoia 15 or later. On iOS 18, iPadOS 18, macOS Sequoia 15, watchOS 11, visionOS 2 and later there are three settings:

• Off uses the hardware address.
• Fixed keeps one private address for that network. It is the default for new networks using WPA2 or stronger security.
• Rotating changes the address every two weeks. It is the default for networks with weak or no security.

Erase All Content and Settings, or resetting network settings, gives the device a new private address on its next join. On iOS 18 and later, forgetting a network also removes its private address unless it was last forgotten less than 24 hours earlier. Both explain a phone a DHCP reservation suddenly stops recognising. Organisations can disable the feature on enrolled devices with an MDM profile.

Windows

Microsoft's support page describes two controls: "All networks" uses random addresses while scanning and when connecting to any network, and "A specific network" applies them on the next connection to that network. On Windows 11 look under Settings, Network and internet, Wi-Fi, Random hardware addresses, or Manage known networks for one network. Windows 10 labels it "Use random hardware addresses". It works only if your Wi-Fi hardware supports it.

Linux

On most desktop distributions NetworkManager decides. Its 802-11-wireless settings include cloned-mac-address, which accepts an explicit address or values such as random and stable, and mac-address-randomization with 0 (default), 1 (never) and 2 (always). Distribution defaults differ, so check:

nmcli -f 802-11-wireless.cloned-mac-address,802-11-wireless.mac-address-randomization \
  connection show "Cafe WiFi"

# Stable random address per network; or use "random" for a new one each time
nmcli connection modify "Cafe WiFi" 802-11-wireless.cloned-mac-address stable

What randomization does not fix

Randomization hides one identifier. It does not hide your hostname in DHCP requests, the network names your device asks for, your login on a captive portal, or the accounts you sign into once connected. On wired Ethernet most systems still send the burned in address. Treat it as a useful layer, not anonymity.

What do checksum offload, TSO, LRO and RSS do?

Offloads move repetitive per packet work from the CPU to the NIC. At 1 Gb/s they were a nice saving. At 100 Gb/s and above, a host cannot keep up without them.

Reading and changing offloads

The ethtool manual documents -k to show features and -K to change them, with short names rx, tx, sg, tso, gso, gro, lro, rxvlan, txvlan, ntuple and rxhash. Your driver may print longer names such as tcp-segmentation-offload; use whatever ethtool -k shows.

# What is on right now?
ethtool -k eth0

# Turn off LRO on a host that bridges or routes traffic
sudo ethtool -K eth0 lro off

# Temporarily disable TX checksum and TSO to get honest packet captures
sudo ethtool -K eth0 tx off tso off
# ...capture...
sudo ethtool -K eth0 tx on tso on

Changes made with ethtool -K do not survive a reboot. Put them in your network configuration (NetworkManager, systemd-networkd or your distribution's equivalent) if you need them permanently.

RSS, RPS, RFS and XPS in Linux

The kernel's scaling documentation describes RSS as hardware: the NIC hashes header fields, typically a Toeplitz hash over the 4 tuple, and an indirection table maps the hash to a receive queue with its own interrupt. It suggests the table be at least four times the queue count. RPS is the software equivalent, controlled by /sys/class/net/<dev>/queues/rx-<n>/rps_cpus and off by default. RFS steers each flow to the CPU running the consuming application, accelerated RFS asks the NIC to do that in hardware, and XPS picks the transmit queue from the sending CPU.

ethtool -l eth0          # queues (channels) available and in use
ethtool -x eth0          # RSS indirection table and hash key
sudo ethtool -X eth0 equal 8
grep eth0 /proc/interrupts

The security angle: offloads mean the NIC parses headers in firmware before the operating system does, and host side capture tools see traffic the NIC has already reshaped. When a sensor or capture looks wrong, check offloads first.

What is SR-IOV, and why does it matter for isolation?

Single Root I/O Virtualization lets one PCIe device present itself as many. In the kernel documentation's terms, the physical device is the Physical Function (PF) and the devices created from it are Virtual Functions (VFs), each with its own routing ID and register space, so a guest drives it like a real card and bypasses the hypervisor's software switch. The recommended way to create VFs on new devices is sysfs:

# How many VFs does the PF support, and how many exist now?
cat /sys/bus/pci/devices/0000:3b:00.0/sriov_totalvfs
cat /sys/bus/pci/devices/0000:3b:00.0/sriov_numvfs

# Create 4 VFs (numvfs must be 0 first)
echo 0 | sudo tee /sys/bus/pci/devices/0000:3b:00.0/sriov_numvfs
echo 4 | sudo tee /sys/bus/pci/devices/0000:3b:00.0/sriov_numvfs

Setting sriov_drivers_autoprobe to 0 before creating VFs stops host drivers binding to them, keeping them free for virtual machines.

Isolation is a configuration, not a given

SR-IOV moves the trust boundary into hardware and the PF driver. The ip-link manual documents per VF controls, run against the PF:

# Pin each VF to an address and VLAN chosen by the host, not the guest
sudo ip link set dev ens1f0 vf 0 mac 02:00:00:00:00:10
sudo ip link set dev ens1f0 vf 0 vlan 100

# Drop frames the guest sends with a source MAC that is not its own
sudo ip link set dev ens1f0 vf 0 spoofchk on

# Keep "trust" off unless the guest genuinely needs promiscuous or multicast features
sudo ip link set dev ens1f0 vf 0 trust off

# Review the result
ip link show dev ens1f0

The manual describes trust as letting the VF user enable features "with security or performance impact", which is exactly why it should default to off. Beyond the NIC itself, VF isolation relies on the platform IOMMU (Intel VT-d or AMD-Vi) being enabled so a VF's DMA cannot reach memory outside its assigned guest, and on keeping the PF driver and NIC firmware current, because a bug there sits below every tenant.

What are SmartNICs and DPUs?

A SmartNIC adds programmable processing to a network card (pipelines, FPGAs or cores) for functions such as virtual switching, encryption or telemetry. A DPU (data processing unit) puts a full system on chip on the card, with its own cores, memory, storage and management controller, so infrastructure software runs apart from the host.

NVIDIA's BlueField-3 user guide gives a concrete example, described here only from the vendor's documentation:

• It supports Ethernet and InfiniBand at up to 400 Gb/s.
• It integrates 8 or 16 Arm cores (64 bit A78), a DRAM controller, an RDMA capable network adapter and an embedded PCIe switch.
• The card carries 16 GB or 32 GB of DDR5 memory with ECC, an onboard SSD for its own operating system, logs and applications, eMMC for its BIOS, and separate flash for its own BMC image.
• NVIDIA says it offloads, accelerates and isolates software defined networking, storage, security and management functions, programmable through its DOCA framework.

Read as a security engineer, that is a server inside your server: firmware, an operating system with open source components, its own management controller, and a patch schedule. Moving infrastructure code off the tenant's CPU is a real isolation gain, and the card is also new attack surface. Our post on the BMC firmware supply chain applies closely to the management side of these cards.

How are NIC firmware and drivers updated, and why does that matter?

A modern NIC has at least two pieces of software: the driver in the host operating system and the firmware on the card. Many also have an option ROM or UEFI driver for network boot, and pluggable optics carry their own EEPROM data. Each can have bugs, and the firmware is the part teams forget.

Updates arrive through operating system updates (Linux kernel drivers and the linux-firmware package, Windows Update and vendor driver packages), vendor firmware utilities, and on Linux the kernel's own flashing path: the ethtool manual documents ethtool -f devname file [N], which writes an image from a kernel firmware directory such as /lib/firmware, with region 0, the default, writing all regions.

ethtool -i eth0                                   # driver, versions, PCI address
lspci -nnk | grep -A3 -i -E "ethernet|network"    # controller and kernel driver
sudo ethtool -m eth0                              # optics module EEPROM details

Warning before flashing. Firmware written to the wrong device, or built for a different board revision, can leave a card unusable. Confirm the interface and PCI address, check the image's model and revision against vendor documentation, keep console access in case the link drops, and do one machine before a fleet.

# Confirm which device you are about to flash
ethtool -i eth0 | grep -E "driver|firmware-version|bus-info"
lspci -s $(ethtool -i eth0 | awk '/bus-info/{print $2}') -nnk
# Only then, with the vendor's image in /lib/firmware:
# sudo ethtool -f eth0 vendor-image.bin

Why it matters: driver and firmware parse untrusted network input before any firewall rule runs, and they decide whether randomization, SR-IOV isolation or Wake-on-LAN behave as documented. Recorded firmware versions are how you answer "are we affected?" when a NIC advisory lands.

What did the 2017 Intel AMT advisory show about out of band management?

Out of band management lets an administrator reach a machine's console, power controls and sometimes its disks over the network, even when the operating system is off or broken. On servers this is usually a BMC. On many business PCs it has been built into the chipset's management engine and shares the main network port.

In May 2017 that model got a hard lesson. NVD lists CVE-2017-5689, published 2 May 2017, with this description: an unprivileged network attacker could gain system privileges on provisioned Intel manageability SKUs, Intel Active Management Technology (AMT) and Intel Standard Manageability (ISM), and an unprivileged local attacker could provision manageability features on AMT, ISM and Intel Small Business Technology (SBT). NVD's CVSS 3.1 score is 9.8, and CISA added it to the Known Exploited Vulnerabilities catalogue on 28 January 2022. Intel's own advisory is INTEL-SA-00075; Intel's site blocked our automated fetch, so the affected and fixed firmware versions should be read directly from that advisory rather than from this post.

The lessons travel beyond one vendor:

1. Management paths are network services. When they share the operating system's port, host firewalls do not protect them, because the traffic is handled before the OS sees it.
2. Provisioning state matters. NVD separates provisioned systems (network attack) from local provisioning. Know which machines have management enabled at all.
3. Fixes arrive as firmware, through each PC or board maker, not through the usual OS patch channel.
4. Inventory sets response time. You cannot patch what you have not listed.

What are Wake-on-LAN and NC-SI sideband, and how should they be configured?

Wake-on-LAN

Wake-on-LAN lets a powered down machine listen for a special frame and power itself on. The ethtool manual lists the options: p (PHY activity), u (unicast), m (multicast), b (broadcast), a (ARP), g (MagicPacket), s (require a SecureOn password for MagicPacket, set with sopass), f (filters) and d (disable all).

# Current setting: look for "Supports Wake-on" and "Wake-on"
sudo ethtool eth0 | grep -i wake

# Disable on machines that do not need it
sudo ethtool -s eth0 wol d

# Enable MagicPacket only, where remote wake is genuinely used
sudo ethtool -s eth0 wol g

Apart from the optional SecureOn password, the MagicPacket carries no authentication, so anyone on the broadcast domain can wake a machine. That is usually a nuisance rather than a breach, but enable it only where you use it, ideally on management VLANs. On Windows, the same choices live in the adapter's Power Management and Advanced properties.

NC-SI and shared management ports

Many servers let the BMC share a host network port. The BMC talks to the NIC over a sideband defined by the DMTF's Network Controller Sideband Interface (NC-SI) specification, and the NIC hands management traffic to the BMC. It saves a cable, and it makes the management controller reachable on whatever network that port joins. Guidance:

• Prefer a dedicated management port on an isolated management network for BMCs.
• If you must share, put the BMC's traffic on its own VLAN and restrict who can route to it.
• Disable management interfaces on machines that do not use them.
• Inventory and patch BMC and NIC firmware together, because the sideband path depends on both.

How do you inspect NIC details on each operating system?

These commands are read only. They tell you which card, driver and firmware, address, speed and offloads you have.

Linux

# Interfaces, state, current MAC (link/ether) and, where shown, the permanent address
ip link show
ip -details link show dev eth0

# Speed, duplex, autonegotiation, link detected, Wake-on
sudo ethtool eth0

# Driver, driver version, firmware version, PCI bus address
ethtool -i eth0

# Burned in (permanent) address, versus whatever is configured now
ethtool -P eth0

# Offloads and queues
ethtool -k eth0
ethtool -l eth0

# PCI view: vendor and device IDs [vvvv:dddd] and the kernel driver in use
lspci -nnk | grep -A3 -i -E "ethernet|network"

# Wireless details (iw is in most distributions)
iw dev

If ip link shows a locally administered address and ethtool -P shows a different one, randomization or a cloned address is in effect.

Windows (PowerShell)

Microsoft documents Get-NetAdapter with -Physical to list physical adapters, -IncludeHidden to show hidden ones, and views for driver and name details:

# Physical adapters with MAC address, link speed and status
Get-NetAdapter -Physical | Format-Table Name, InterfaceDescription, MacAddress, LinkSpeed, Status

# Driver version, provider and date
Get-NetAdapter -Name * | Format-Table -View Driver

# Every property for one adapter
Get-NetAdapter -Name "Ethernet" | Format-List -Property *

# Offloads, RSS, SR-IOV and Wake-on-LAN related settings
Get-NetAdapterAdvancedProperty -Name "Ethernet"
Get-NetAdapterRss -Name "Ethernet"
Get-NetAdapterSriov
Get-NetAdapterPowerManagement -Name "Ethernet"

# Quick check from cmd
getmac /v

macOS

# Every hardware port, its device name (en0, en1...) and its burned in address
networksetup -listallhardwareports

# Current address in use (can differ on Wi-Fi when a private address is active)
ifconfig en0 | grep ether

# Media and link details
networksetup -getmedia "Wi-Fi"
system_profiler SPNetworkDataType | head -60

On a network using a private Wi-Fi address, the two addresses differ, which confirms the feature is working.

Step by step: audit the network cards on one machine in 15 minutes

1. List every adapter, physical and virtual, with the commands above.
2. Record driver and firmware versions (ethtool -i, or the Driver view on Windows) in the machine's inventory record.
3. Compare the Wi-Fi address in use with the permanent address. Confirm randomization is on for devices that roam, and turn it off only deliberately.
4. Review offloads on hosts that route, bridge or capture traffic. Turn LRO off on forwarding hosts.
5. Disable Wake-on-LAN where nobody uses it.
6. On virtualization hosts, review SR-IOV: IOMMU on, host assigned MACs and VLANs, spoofchk on, trust off.
7. Find management paths: a BMC or chipset management engine, whether it is provisioned, whether it shares a host port, and its firmware version.
8. Add any DPU or SmartNIC to the inventory as a separate computer with an owner and patch schedule.

Common mistakes

• Treating randomization as anonymity. It hides one identifier. DHCP hostnames, captive portal logins and account sign ins still identify you.
• MAC allow lists. Private addresses will not match a list built from burned in addresses. Move to certificate or account based access, or choose Fixed deliberately.
• Debugging with offloads on. Captures on the sending host show bad checksums and frames bigger than the MTU because of checksum offload and TSO. That is expected, not corruption.
• Leaving LRO on routers and bridges. Merged frames cannot be forwarded as received. Turn it off on any host that forwards traffic.
• Assuming SR-IOV equals isolation. Without the IOMMU, spoof checking and host assigned MACs, VFs share more than you think.
• Patching drivers but never firmware. The OS update path does not touch most NIC firmware. Track firmware versions separately.
• Forgetting the DPU is a computer. It has an OS, packages and a management controller. If it is not in the inventory, nobody patches it.
• Exposing management ports. A BMC reachable from user networks turns a firmware bug into a remote takeover path.

Fix it without waiting for upstream

Network cards are hardware, but the software around them is ordinary supply chain material: Linux images carry drivers and linux-firmware packages, Wi-Fi stacks such as wpa_supplicant and hostapd ship inside appliances, and DPUs run full operating systems built from open source packages. When a host or DPU image is rebuilt, those components come back at whatever version the build pulls, so the same discipline you use for application dependencies applies to them.

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.

Where Safeguard fits, honestly

Safeguard does not read NIC firmware, flash cards, configure MAC randomization, manage devices, provide endpoint protection or generate hardware bills of materials; that work is done with the OS tools above and vendor firmware updates. It helps with the software around the hardware: scanning the container images you build, including driver, firmware and Wi-Fi or DPU user space packages inside them; analysing vendor supplied SBOM files, since CycloneDX can describe firmware and device components; matching components against vulnerability databases; and showing which projects contain a given component and version when an advisory lands. Policies and gates can stop an image with a known vulnerable component from shipping.

FAQ

Can someone tell my device's manufacturer from its MAC address?

Usually, yes, for burned in addresses. The first 24 bits typically come from an IEEE assigned block, and the IEEE publishes those assignments. Randomized addresses set the locally administered bit, so there is no vendor to look up.

Is MAC randomization on by default?

On Android 10 and later, and on Apple devices from iOS 14, watchOS 7 and macOS Sequoia 15, yes, for Wi-Fi. On Windows it is a setting you can turn on for all networks or per network. On Linux it depends on your distribution's NetworkManager defaults.

Why does my phone's MAC address keep changing on my home network?

On Apple devices running iOS 18 or later, networks with weak or no security default to Rotating, which changes every two weeks. Erasing the device or resetting network settings also triggers a new address. Set the network to Fixed if your router relies on a stable address.

Does a VPN hide my MAC address?

No. Your MAC address only appears on the local network segment, such as your Wi-Fi or office LAN. A VPN encrypts traffic beyond that point; it does not change what the local access point sees. MAC randomization is the control for that.

Should I disable TCP offloading?

Usually not. Offloads save CPU and are tested defaults. Disable LRO on hosts that route or bridge, and temporarily disable checksum and segmentation offload when you need accurate packet captures, then turn them back on.

Is SR-IOV secure for multi-tenant virtual machines?

It can be, with the IOMMU enabled, host assigned MACs and VLANs, spoof checking on, trust off, and current PF drivers and NIC firmware. Without those, a guest may influence traffic it should not.

What is the difference between a SmartNIC and a DPU?

A SmartNIC adds programmable offload to a network card. A DPU is a SmartNIC with a full system on chip: its own CPU cores, memory, storage, operating system and often its own management controller. Treat a DPU as a separate computer.

Is Wake-on-LAN a security risk?

Mostly a low one. MagicPackets are unauthenticated, so anyone on the same broadcast domain can wake a machine, but that alone does not grant access. Disable it where unused and limit it to management networks where needed.

See how Safeguard would help

To try these on your own machine, download Safeguard and follow the CLI docs.

This is a real Safeguard CLI session: it reads a finding and its advisory, asks before each command, edits package.json, runs npm install and tests with your approval and pushes nothing. The example is an npm dependency, not a NIC driver, but the same flow applies when a host or DPU image build pulls a vulnerable user space package.

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

This one sets up the local runner on your own machine, approves it with its device code and scans from the terminal. It suits lab and build machines for appliance or DPU images, where scanning should run next to the image.

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

Quick check

Sources

• IEEE 802.3 Ethernet Working Group
• IEEE P802.3df 400 Gb/s and 800 Gb/s Ethernet Task Force
• IEEE P802.3dj 200 Gb/s, 400 Gb/s, 800 Gb/s and 1.6 Tb/s Ethernet Task Force
• IEEE 802.3 reflector: P802.3dj initial Standards Association ballot results, March 2026
• IEEE 802.3 reflector: P802.3dj second Working Group recirculation ballot results, October 2025
• IEEE P802.3bs 200 Gb/s and 400 Gb/s Ethernet Task Force
• IEEE P802.3ba 40 Gb/s and 100 Gb/s Ethernet Task Force
• IEEE P802.3by 25 Gb/s Ethernet Task Force
• IEEE P802.3bz 2.5G/5GBASE-T Task Force
• IEEE P802.3ae 10 Gb/s Ethernet Task Force
• IEEE P802.3ab 1000BASE-T Task Force
• IEEE P802.3z Gigabit Task Force
• IEEE Registration Authority
• Ethernet Alliance: Ethernet Roadmap
• Microsoft Support: How to use random hardware addresses in Windows
• Apple Support: Use private Wi-Fi addresses on Apple devices
• Android Open Source Project: MAC randomization behavior
• NetworkManager: 802-11-wireless settings
• Linux kernel: Scaling in the Linux networking stack
• Linux kernel: PCI Express I/O Virtualization Howto
• ethtool(8) manual page
• ip-link(8) manual page
• Microsoft Learn: Get-NetAdapter
• NVIDIA BlueField-3 Networking Platform User Guide: Introduction
• NVD: CVE-2017-5689
• Safeguard: Does your network card keep your browsing history?
• Safeguard: How Ethernet switching works, MAC learning and VLANs
• Safeguard: Hardware BMC firmware supply chain in 2026

Last reviewed: 23 October 2026.