Wi-SUN FAN Explained: Utility Meter Mesh Networks and How to Secure Them

Wi-SUN FAN (Field Area Network) is an open, certified IPv6 wireless mesh profile that utilities and cities use to connect smart meters, streetlights and grid sensors. It runs IEEE 802.15.4g radios with frequency hopping, 6LoWPAN, RPL routing and 802.1X EAP-TLS joins. You secure it through certificate lifecycle, border router hardening, key rotation and disciplined firmware updates.

The Wi-SUN Alliance writes the profile and certifies products against it. Since July 2026 the FAN specification is also an international standard, ISO/IEC/IEEE 32857:2026. This post sits next to our LoRaWAN explainer and our DNP3 explainer. Here we go one level deeper on the mesh itself: each layer of the stack, how the mesh forms and heals, how a meter proves its identity and receives keys, the risks that matter over a twenty year meter life, and a lab walkthrough with an open source Linux border router.

Key takeaways

• Wi-SUN FAN is a profile, not a single new protocol. It selects and constrains existing standards: the IEEE 802.15.4 Smart Utility Network (SUN) radio, IEEE 802.15.4 MAC frames with Wi-SUN information elements, 6LoWPAN header compression (RFC 6282), IPv6, RPL routing (RFC 6550), DHCPv6, and 802.1X with EAP-TLS for access control.
• A FAN has three roles. The border router connects the mesh to the utility's IP network, keeps source routes for every node, authenticates nodes and hands out group keys. Router nodes forward traffic and relay joins. Leaf nodes, including the low power Low Function Nodes (LFNs) added in FAN 1.1, only send and receive.
• Each device carries an X.509 device identity certificate in the IEEE 802.1AR style, issued by a Wi-SUN third party certificate authority or by the manufacturer's own CA. EAP-TLS mutual authentication with ECDSA certificates produces a pairwise master key, a four way handshake produces a pairwise transient key, and the border router distributes a set of four group keys used for AES-CCM* frame security on every hop.
• FAN 1.1 adds optional OFDM PHY modes with link rates up to 2.4 Mbit/s, low power leaf nodes for battery water and gas meters with ten year battery targets, and more bands in the 800 and 900 MHz ranges. FAN 1.0 and 1.1 devices can share a network, with configuration caveats.
• The radio is rarely where things go wrong. The risks that matter are certificate and key lifecycle over a meter life measured in decades, a Linux border router exposed on the utility network, interference and jamming on unlicensed bands, slow firmware distribution over a constrained mesh, and the open source and vendor software inside border routers and head end systems.

What is Wi-SUN, and who runs the Wi-SUN Alliance?

Wi-SUN stands for Wireless Smart Utility Network. The name refers both to a family of specifications built on the SUN radio layers of IEEE 802.15.4 and to the Wi-SUN Alliance, the industry body that writes those profiles and runs the certification programs.

According to the Alliance's own history page, the group traces its origins to the US Energy Independence and Security Act of 2007, which pushed utilities toward smart grid investment. Founders came together in 2011 and the Alliance was formed in January 2012; its press releases describe it as founded in Japan in 2011, so you will see both years quoted. Utilities that feared being locked into a single meter network vendor wanted an open radio standard with a wide supplier base, and that remains the Alliance's central pitch.

Membership spans silicon vendors, module makers, product companies, universities and utilities. The Alliance's 2026 releases put membership at more than 300 organizations across 46 countries. Members fall into tiers (Promoter, Contributor, Adopter and others), and the tier matters in practice: the full FAN 1.1 technical profile specification is downloadable only by Contributor and Adopter members, and obtaining production device certificates through the Alliance's CA program requires Promoter or Contributor membership.

The Alliance does three things that matter for security teams:

1. It writes the profiles. The FAN Technical Profile Specification (TPS) defines exactly which options of each underlying standard a FAN device must implement, and the PHY TPS defines radio parameters per region.
2. It certifies products. FAN certification requires PHY certification plus upper layer profile testing at Alliance appointed third party labs.
3. It runs a certificate authority program. Commercial CAs operate a Wi-SUN FAN third party PKI that issues test and production device identity certificates to members.

The Alliance also says plainly what it does not do. It does not publish a reference implementation of the stack, and it does not audit certificate authorities: its certificate page states that ensuring the integrity and security of the CA is the responsibility of the customer and the manufacturer. That single sentence is the root of most of the lifecycle advice later in this post.

What does the FAN profile cover?

The Alliance describes a Field Area Network as communications infrastructure for very large scale outdoor networks, letting devices such as smart meters and streetlights share one common network. RFC 8376, the IETF's 2018 overview of low power wide area technologies, carries a section contributed by Wi-SUN proponents that lists the target applications: advanced metering infrastructure (AMI), distribution automation, SCADA protection and management, distributed generation monitoring, electric vehicle infrastructure and smart city infrastructure.

The FAN profile covers everything from the radio up to the transport layer: PHY modes and channel plans, frequency hopping schedules, frame formats and information elements, network discovery, joining, authentication and key management, IPv6 adaptation, addressing and routing, and multicast. It does not define the application. Meter reading protocols, lighting control commands and head end interfaces run over UDP or TCP on top of the FAN, which is why RFC 8376 calls the profile an "application-independent IPv6-based transport service".

Wi-SUN also has other profiles, notably the Home Area Network (HAN) profile, now at HAN 2.0, which the Alliance describes as linking electricity meters, energy management systems and household devices in the connected energy home. HAN and FAN share the same IEEE 802.15.4 SUN radio layer, so one radio module can support both. This post covers FAN only.

FAN 1.0 and FAN 1.1

FAN 1.0 is the profile most deployed meters run. The IEEE adopted the Wi-SUN FAN specification as IEEE 2857-2021, "IEEE Standard for Wireless Smart Utility Network Field Area Network (FAN)", approved by the IEEE SA Standards Board on 16 June 2021 and published on 25 June 2021. The Alliance's FAQ points developers to IEEE 2857-2021 as the public way to read the FAN 1.0 specification without membership. On 7 July 2026 the Alliance announced that the FAN specification had been ratified as ISO/IEC/IEEE 32857:2026, and described it as the first wireless mesh networking specification adopted as an ISO/IEC standard.

FAN 1.1 is the current version. The Alliance lists these changes:

• Higher link speeds. Optional OFDM PHY modes support link rates up to 2.4 Mbit/s. OFDM is optional for FAN 1.1 certification; certified devices can continue to use FSK.
• Low power nodes. Low Function Nodes (LFNs) are battery or energy harvesting leaves with their own timing and keying, aimed at water and gas meters and field sensors that need ten or more years on a battery.
• More regions. Additional frequency bands in the 800 and 900 MHz ranges extend FAN to more of Europe, Asia and Latin America, with the Alliance naming Brazil, India and Japan.
• Distribution automation latency. The Alliance positions 1.1 for low latency distribution automation alongside metering.

The Alliance says FAN 1.1 is fully compatible with FAN 1.0 networks and that FAN 1.0 devices continue to be certified and sold. The operational detail is subtler. The documentation of an open source Linux border router notes that the way the standard was written "does not allow to safely mix FAN 1.0 devices with LFNs", so its default configuration accepts LFNs and refuses FAN 1.0 routers unless you set an explicit option. Mixed networks work, but you choose which compatibility you get.

Timeline: Wi-SUN FAN and the standards underneath it

IEEE 802.15.4-2020 now shows as superseded on the IEEE SA site, and several later amendments extend the SUN PHYs, including one for SUN PHYs supporting data rates up to 2.4 Mb/s. Check which edition and amendments your devices' PHY certification references.

How is the Wi-SUN FAN stack built?

RFC 8376 gives the clearest public summary of the stack. Reading it bottom to top:

The radio: IEEE 802.15.4 SUN PHY

The original 2.4 GHz 802.15.4 PHY that Zigbee and Thread use was designed for short indoor links. The Smart Utility Network amendment, 802.15.4g, added sub-GHz PHYs built for outdoor, multi kilometre utility links, and those PHYs were later folded into the base standard. The Wi-SUN PHY profile picks a subset. RFC 8376 describes the FAN PHY as 2-FSK modulation with channel spacing from 200 to 600 kHz and data rates from 50 to 300 kbit/s, with forward error correction optional. FAN 1.1 adds OFDM modes; the Alliance FAQ cites link speeds up to 2.4 Mbit/s.

Bands are regional. The Alliance FAQ lists 902 to 928 MHz for North America and Brazil, 863 to 870 MHz and 870 to 876 MHz for Europe, 865 to 867 MHz for India, 920 to 928 MHz for Japan, and 866 to 869 MHz plus 902 to 928 MHz for Singapore. Channel width and count depend on the region, modulation and data rate mode, and the details live in the member only PHY TPS. On the open source border router, you choose a regulatory domain, a channel plan identifier and a PHY mode identifier in the configuration file and can ask the daemon to list the combinations your radio supports.

RFC 8376 gives a typical line of sight range of 2 to 3 km per hop, extended by multi-hop forwarding.

The MAC: frequency hopping and information elements

FAN nodes do not sit on one channel. Each node publishes a unicast listening schedule: a sequence of channels and a dwell interval per channel. A neighbor that wants to send to it computes which channel the receiver is on at that moment and transmits there. The border router also sets a network wide broadcast schedule, so broadcast frames go out on a channel everyone is tuned to at a known time.

The open source border router's example configuration exposes the knobs: a unicast dwell interval (default 255 ms), a broadcast dwell interval (default 255 ms), a broadcast interval (default 1,020 ms) and an allowed channel mask. If you restrict the mask to a single channel, hopping is disabled and the network runs in fixed channel mode. The mask affects unicast and broadcast traffic but not the asynchronous discovery frames.

Hopping helps with unlicensed band rules and with narrowband interference. It is not a security control. Hop sequences are derived from public parameters and schedules are advertised in frame information elements, so anyone who can decode the frames can follow the hops.

Information elements (IEs) are the extension mechanism of the 802.15.4 frame format. Wi-SUN defines header IEs for things like the unicast timing and the frame type, and payload IEs for the PAN identifier, routing cost, network name, broadcast schedule and the GTK hash. RFC 8376 notes that the entire MAC payload is wrapped in an IEEE 802.15.9 style information element so the receiver can dispatch it either to 6LoWPAN or to an optional MAC layer mesh service.

The adaptation layer: 6LoWPAN header compression

An IPv6 header is 40 bytes and a UDP header 8 bytes. On a link where frames are small and every byte costs airtime and battery, that overhead matters. RFC 6282 defines LOWPAN_IPHC, which elides IPv6 header fields that can be inferred from the link layer or from shared context, and LOWPAN_NHC, which compresses next headers such as UDP.

Worked example 1: how much header does 6LoWPAN save?

Take a UDP datagram between two neighbors using link-local addresses derived from their MAC addresses, with default traffic class and flow label, a hop limit of 255 and UDP ports in the compressible range.

• Uncompressed: 40 bytes IPv6 plus 8 bytes UDP = 48 bytes.
• LOWPAN_IPHC base encoding: 2 bytes. Traffic class and flow label are elided (TF = 11). Next header is compressed with NHC. Hop limit 255 is encoded in the base bits. Both addresses are fully elided (SAM = 11 and DAM = 11) because RFC 6282 derives the interface identifier from the encapsulating 802.15.4 header.
• UDP NHC: 1 byte of NHC header, 1 byte for both ports when they fall in the 0xF0B0 to 0xF0BF range (4 bits each), and 2 bytes for the checksum, which RFC 6282 only lets you elide when an upper layer authorizes it. That is 4 bytes.
• Total: 2 + 4 = 6 bytes instead of 48, a saving of 42 bytes or 87.5 percent.

A meter reading bound for the head end saves less: the head end's 128 bit address usually travels in full (16 bytes), and the multi-hop RPL data path adds routing information. Design payload formats for small frames rather than assuming LAN sized packets.

The Linux border router sets its TUN interface MTU to 1,280 bytes, the IPv6 minimum, and relies on 6LoWPAN fragmentation to carry those packets across 802.15.4 frames.

The network layer: IPv6, registration and RPL

Every FAN node is an IPv6 host with a link-local address and a global address. The border router (or an external DHCPv6 server behind it) assigns global addresses, and the README of the Linux border router notes that FAN interfaces cannot be configured through SLAAC router advertisements.

Neighbor discovery on a lossy, sleepy mesh cannot rely on multicast solicitations the way Ethernet does. RFC 6775 replaced most of that with explicit address registration: a host registers its address with a router, which keeps the binding. RFC 8505 extended that with the Extended Address Registration Option (EARO), a Registration Ownership Verifier, and a transaction identifier, so a router can tell a fresh registration from a stale one and so a registration can carry information a routing protocol can use. RFC 9010 then specified how a leaf that registers through RFC 8505 can be routed by RPL without running RPL itself, which is the pattern low power leaves need.

Routing uses RPL, specified in RFC 6550. RPL builds a Destination Oriented Directed Acyclic Graph (DODAG) rooted at the border router:

• The root sends DIO (DODAG Information Object) messages carrying the DODAG identity, version, and its rank. DIO timing follows the Trickle algorithm, so a stable network sends few control messages and a disturbed network speeds up.
• Each node computes its own rank from its preferred parent's rank plus a link cost, using an objective function. Rank must increase moving away from the root; that rule is how RPL avoids loops.
• Nodes send DAO (Destination Advertisement Object) messages upward so the root learns how to reach them. In non-storing mode, intermediate routers keep no downward routes; the root assembles a source route for each destination from the DAO parent information and inserts it into downward packets.

RFC 8376 confirms the FAN pattern: the border router "maintains source-routing tables for all nodes within its network". RPL messages are ICMPv6 type 155, and the Linux border router's troubleshooting guide lists that type as one that must not be blocked on its TUN interface.

How does the mesh form and heal?

Joining a FAN is a staged process. In the language of the Linux border router's documentation, a node moves through join states, with state 4 being the point at which it is waiting for RPL and DHCPv6 responses. Conceptually, the stages are:

1. Discover a PAN. The node sends PAN Advertisement Solicit frames and listens for PAN Advertisements. Advertisements carry the network name, PAN identifier and a routing cost that tells the node how far each candidate is from a border router. The node prefers the lowest cost PAN with the right network name.
2. Authenticate. The node runs 802.1X with EAP-TLS through a neighbor that wraps its EAPOL frames in EAPOL relay packets toward the border router, then completes key handshakes to receive the current group keys.
3. Acquire the PAN configuration. The node sends PAN Configuration Solicit frames. With the group keys installed it can decode the secured PAN Configuration frames that carry the broadcast schedule and GTK hashes, synchronize to the broadcast schedule and confirm it holds the active keys.
4. Configure routing. The node sends RPL DIS messages, listens for DIOs and picks a preferred parent using RPL metrics. It obtains a global IPv6 address over DHCPv6 (relayed by its parent), registers that address with the parent using a neighbor solicitation carrying an address registration option, and sends a DAO so the border router learns a downward route to it.
5. Operate. The node carries application traffic. If it is a router, it now does for others what its neighbors did for it: it sends PAN Advertisements and PAN Configurations, relays EAPOL and DHCPv6 for children, answers DIS with DIOs, processes registrations and forwards multicast using MPL.

This sequence is spelled out in the feature list of the experimental Linux FAN router (wsrd) that ships in the same open source repository as the border router, which is a useful public reference because the FAN specification itself is member only.

Healing is a property of RPL and the hopping MAC working together. Each node keeps a set of candidate parents and can register a secondary parent in advance. When a link to the preferred parent degrades (link metrics such as expected transmission count rise, or acknowledgements stop), the node switches to another parent with acceptable rank and sends a fresh DAO; the border router's source route table updates. A router that can no longer reach the border router poisons its DIOs so its children look elsewhere, and a node leaving on purpose sends a DAO No-Path so the border router drops its route. If a whole subtree loses its path, nodes can detach and rejoin through another route. The Alliance's FAQ describes the result simply: if a device or collection node loses power, nearby devices connect around it.

One operational consequence is worth knowing in advance. The Linux border router documentation notes that after a restart it restores its neighbor cache and routes but loses its neighbors' hopping timing, so downstream traffic stops until each neighbor sends it a frame, and LFNs that miss their time sync frames treat the parent as gone and perform a full join. Border router restarts are not free in a large mesh, which is one reason to plan maintenance windows and to avoid restarting them casually during incidents.

Node roles: border router, router and leaf

RFC 8376 describes a low power network shape where routers at the edges form a star with leaf nodes. In practice, mains powered electricity meters often serve as the routers that battery meters hang off.

How does joining and authentication work?

The security architecture comes almost entirely from Wi-Fi enterprise and from IEEE 802.1AR device identity, adapted to a mesh where the authenticator may be many hops away.

Device identity certificates

The Wi-SUN Alliance's certificate page states that the FAN Technical Profile Specification requires FAN devices to contain device identity certificates issued either from a Wi-SUN third party CA or from a manufacturer CA. Those are IDevIDs in IEEE 802.1AR terms: an X.509 certificate and private key installed at manufacture that bind a hardware identity to a key pair. The third party PKI program issues test and production IDevIDs and can work with members or their customers to deploy LDevIDs, locally significant identities that an operator installs for its own network.

The open source border router's README notes that the certificate generation process is in section 6.5.1 of the Wi-SUN specification, uses standard X.509 format, and that "some fields and algorithms are enforced". RFC 8376 records the cipher suite required for EAP-TLS: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, which means elliptic curve keys, ECDSA signatures, an ephemeral ECDH exchange and AES-128 in CCM mode with an 8 byte tag.

The handshake sequence

1. EAPOL relay. A joining node is not yet trusted, so it speaks EAPOL (802.1X frames) only to a neighbor, its EAPOL target. If that neighbor is not the border router, it relays the EAPOL frames over UDP to the authenticator. The Linux border router lists UDP port 10253 for EAPOL relay.
2. EAP-TLS mutual authentication. The node and the authenticator run a TLS handshake inside EAP as described in RFC 5216. Each side validates the other's certificate chain against its trust anchors. The authenticator can be the border router itself or an external RADIUS server (UDP 1812) that the border router talks to.
3. Pairwise Master Key. A successful EAP-TLS exchange produces key material from which both ends derive a Pairwise Master Key (PMK).
4. Four way handshake. Following the IEEE 802.11 four way handshake pattern, the border router and node prove they both hold the PMK and derive a Pairwise Transient Key (PTK), which protects key delivery to that node.
5. Group keys. The border router delivers Group Temporal Keys (GTKs). RFC 8376 notes that a set of four group keys is maintained, one of which is the current transmit key. LFNs get their own LGTKs.
6. Frame security. Every data frame on every hop is protected with AES-CCM* under the active GTK, as specified in IEEE 802.15.4. The PAN Configuration frames carry hashes of the installed GTKs so nodes can tell when they are missing a key.

RFC 8376 also mentions optional node to node keying between one hop neighbors using an adaptation of ETSI TS 102 887-2.

Note what this design gives you and what it does not. Group keys mean link layer protection is hop by hop and shared: every authenticated node in the PAN can decrypt every frame it hears. That is fine for keeping outsiders off the mesh, and it is not end to end confidentiality between a meter and the head end. Applications that need end to end protection must add it above IP.

Key lifetimes and rotation

The open source border router's example configuration documents its defaults, all in minutes. They make a useful worked example of how often keys turn over.

Worked example 2: what the default key lifetimes mean in days

Two further settings shape rotation. The new GTK activation time is the expire offset divided by gtk_new_activation_time: 43,200 / 720 = 60 minutes, so the border router switches to the next group key one hour before the current one expires. For LGTKs, 129,600 / 180 = 720 minutes, or 12 hours. The gtk_new_install_required value of 80 means a new GTK is installed when the current one is 80 percent through its lifetime: 0.8 x 30 days = 24 days, which leaves six days of overlap for every node to receive the next key before the switch.

Revocation works through the same mechanism. When a node is revoked, the border router reduces the lifetime of the active group key by a configured factor (default 30) and distributes fresh keys to the nodes that remain. A 30 day GTK with 24 days left becomes a key with about 0.8 days left, and the revoked node is not given its successor. That is fast enough for normal operations and slow enough that you should understand it before you rely on it during an incident.

Where is Wi-SUN deployed?

The Alliance's materials and RFC 8376 point to the same core uses:

• Electricity AMI. Smart meters reading interval consumption, outage and restoration events, remote connect and disconnect, and firmware updates. The Alliance cites nationwide smart metering in Japan and large projects in North America, Europe and Asia Pacific.
• Gas and water metering. Battery meters that cannot afford to route traffic, the main target of FAN 1.1 LFNs.
• Street lighting and smart city. Streetlight controllers, which are mains powered and mounted high, make good routers; parking, traffic and environmental sensors join the same mesh.
• Distribution automation. Reclosers, switches, capacitor bank controllers and fault indicators where low latency control matters.
• Scale. RFC 8376 reported tens of millions of FAN devices deployed by 2018, including deployments of more than 1 million devices. In October 2026 the Alliance said member companies were deploying more than 2 million endpoints across 60 cities in Brazil alone, for two utilities.

The Alliance's CEO describes FAN as attractive "where utilities want private, utility-controlled networks". Network ownership, multi-vendor procurement and long asset life are the recurring reasons.

How does Wi-SUN compare with LoRaWAN and cellular IoT?

The three answer different questions.

• LoRaWAN is a star of stars. Sensors send single hop uplinks to gateways that forward to a network server. Payloads are small and infrequent, regional duty cycle rules cap airtime in Europe, and devices are not IP endpoints. It is excellent for battery sensors that report a few times a day and rarely need commands. Our LoRaWAN post covers its keys and join procedure.
• NB-IoT and LTE-M run on licensed cellular spectrum managed by a mobile operator. 3GPP finalized NB-IoT in Release 13 in June 2016, and RFC 8376 lists its targets as battery life over 10 years and 164 dB maximum coupling loss. Each device has a SIM and talks directly to the operator's base station. The utility does not build radio infrastructure but depends on the operator's coverage, pricing and network lifetime.
• Wi-SUN FAN is a private, utility owned IPv6 mesh. Mains powered meters relay for each other, links are relatively fast for an IoT radio, every device is addressable by IPv6, and access control uses certificates and 802.1X. The utility owns the infrastructure and the key management, and with it the operational burden.

Many utilities mix them: FAN for dense meter areas, cellular for isolated sites and for border router backhaul.

Comparison table: Wi-SUN FAN, LoRaWAN, NB-IoT and Zigbee

Rates and ranges depend on region, configuration and terrain; treat them as orders of magnitude.

What are the risks, and how do you secure a Wi-SUN FAN?

Wi-SUN's security design is sound for its threat model: keep unauthenticated devices off the mesh, protect frames on every hop, and let the operator rotate and revoke keys centrally. What goes wrong in field networks is mostly operational. NIST IR 7628 Rev. 1, the three volume smart grid cybersecurity guideline, frames AMI as a set of logical interfaces between meters, collectors, head ends and enterprise systems, each needing its own controls, and that framing still fits FAN deployments.

Certificate and key lifecycle over a decades-long meter life

A meter installed this year may stay on the wall for fifteen to twenty years. Its IDevID was minted at the factory, and its trust anchors were chosen before the utility ever saw it.

• Expiry. IEEE 802.1AR lets a supplier install an Initial Device Identifier (IDevID) that an operator can supplement with Local Device Identifiers (LDevIDs). RFC 5280 anticipates exactly this kind of certificate, one that binds a device's model and serial number to its key for the device's whole life, and says such certificates SHOULD use the notAfter value 99991231235959Z. RFC 5280 adds that an issuer that cannot maintain status information until notAfter must make sure no valid certification path exists once it stops. A meter certificate with no meaningful expiry moves the burden to revocation and to the operator's allow lists. Confirm what your devices actually carry rather than assuming.
• Trust anchor rotation. If the CA that signed your meters is retired, compromised, or migrated to new algorithms, every border router must keep trusting the old anchor for as long as those meters live. Plan for multiple trust anchors in the authenticator from the start.
• CA integrity is your problem. The Alliance states it does not evaluate or audit CAs and that CA integrity is the responsibility of the customer and manufacturer. If you use a manufacturer CA, ask for its certificate policy, how its keys are protected and how it would notify you of compromise. If you run your own CA for LDevIDs, treat it as critical infrastructure with offline roots.
• Revocation in practice. EAP-TLS lets the authenticator reject a revoked certificate on the next join, but devices already in the mesh hold valid group keys until rotation. Combine certificate revocation with border router revocation (which shortens the group key lifetime) and with a deny list of MAC addresses.
• Algorithm agility. The required cipher suite is ECDSA based. The IEEE SA lists an approved draft amendment to 802.1AR adding support for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), so post-quantum device identities are on the way at the standards level, but a migration for meters already in the ground will be slow. The practical step today is to inventory which curves and CAs your fleet uses so the eventual migration has a map.

Border router exposure

The border router is the most valuable node in the mesh. It is the RPL root, keeps source routes for every node, often runs the authenticator, holds every group key, and has an IP interface on the utility network.

• It is a computer on your network. In the open source design it is a Linux host running a daemon, with a TUN interface, a DHCPv6 server or relay, optionally a RADIUS client, an optional MQTT client, and a D-Bus interface. Harden it as you would any internet facing Linux server: minimal packages, a firewall, central logging, and patching.
• Drop privileges. The README recommends starting the daemon as root and then switching to an unprivileged user with the user and group settings, or granting only the CAP_NET_ADMIN, CAP_NET_BIND_SERVICE and CAP_NET_RAW capabilities.
• Protect the radio co-processor link. In the Linux design, a radio co-processor (RCP) handles the low level radio and encrypts and decrypts 802.15.4 frames, and the host sends it commands over a UART. The README carries an explicit caution: MAC layer data appears in cleartext on that host interface, so integrators must secure the serial link, and "IEEE 802.15.4 encryption keys can even be stolen" by someone who intercepts the command that transfers them to the RCP. Physical access to a pole top collector is not hard. Use an encrypted host to radio link where the hardware supports it, and tamper evident enclosures.
• Do not bridge the mesh to the internet by accident. The transparent IPv6 proxy feature makes FAN nodes appear as ordinary hosts on the upstream network, and the README notes that if the upstream gateway provides global addresses and no firewall is in the way, hosts on the internet can reach the FAN nodes. Put border routers behind a firewall that allows only the head end and management systems to reach the mesh prefix.
• Separate management. D-Bus, SSH and any web interface on the border router belong on a management network, not on the same interface as head end traffic.

Jamming, interference and routing attacks

• Jamming. Any radio can be jammed. Frequency hopping raises the cost of narrowband jamming but does not stop a wideband jammer. Detection is the realistic control: monitor per node link quality, retransmissions and join churn, and alert when a geographic cluster degrades at once. The Linux border router's "frame spent X sec in RCP" congestion warning is one such signal, although its documentation notes that it usually means a busy radio environment.
• Routing attacks from inside. RPL assumes nodes that hold the group key are honest. RFC 7416, the IETF's threat analysis for RPL, catalogues what a compromised node can do: advertise a misleading rank to attract traffic (a sinkhole), drop packets selectively (selective forwarding), tunnel traffic between distant points (a wormhole), or flood control messages. RFC 6550 defines optional secured RPL control messages, but the FAN profile protects RPL with link layer security, so the realistic controls are fast revocation, monitoring of rank and parent changes, and physical tamper detection.
• Replay and frame counters. 802.15.4 frame security includes a frame counter so receivers can reject replays. A node that reboots and reuses counters under the same key weakens that protection, which is why implementations persist them: the experimental Linux router, for example, stores security keys and frame counters on disk and restores them on restart. Group key rotation also bounds how long captured frames remain useful.
• Join floods. A device that repeatedly attempts EAP-TLS joins can load the authenticator and the relay path. Rate limiting and allow lists on the authenticator help.

Firmware updates over a constrained mesh

Every meter, router and border router runs firmware that will need security fixes over its life, and a FAN has limited bandwidth to deliver them.

Worked example 3: how long does a firmware image take to move?

Take a 512 KiB image (4,194,304 bits).

• At 50 kbit/s, the slowest FSK mode RFC 8376 lists: 4,194,304 / 50,000 = 83.9 seconds of raw airtime per hop for one copy, before MAC overhead, retransmissions and hopping.
• At 300 kbit/s: 4,194,304 / 300,000 = 14 seconds.
• At 2.4 Mbit/s with FAN 1.1 OFDM: 4,194,304 / 2,400,000 = 1.75 seconds.

Now multiply. If 10,000 meters each fetch the image by unicast from the head end and the average path is four hops, the mesh moves the image 40,000 hop transmissions. At 50 kbit/s that is about 3.36 million seconds of raw airtime, close to 39 days if it were all serialized through one channel; spatial reuse and multiple border routers cut this, and real protocol overhead adds to it. That is why vendors use multicast distribution, staged rollouts and delta updates, and why a firmware fix for a fleet takes weeks, not hours.

Security consequences follow directly. Images must be signed and verified on the device, with the public key stored in protected memory; a constrained network makes unsigned updates tempting and catastrophic. Rollback protection matters, because an attacker who can push an older vulnerable image has undone your patch. And because rollouts are slow, a vulnerability in meter firmware leaves a long exposure window that you manage with network controls in the meantime.

Open source and vendor stack dependencies

Wi-SUN stacks are mostly vendor implementations, and the Alliance does not publish a reference stack. The software around them is a supply chain like any other.

• The open source Linux border router requires mbedTLS 3.x for its TLS and EAP-TLS work, libnl and libnl-route for netlink, libcap, and libsystemd (or elogind), plus Rust and Cargo for its command line client. Its README notes that dnsmasq is supported from version 2.87 because of an earlier bug and that ISC DHCP needs patches to comply with the Wi-SUN specification.
• Its license is worth reading before you ship it. The project's license file states that it is a modified version of an Apache 2.0 licensed Wi-SUN FAN stack, with the modifications licensed under the silicon vendor's master software license agreement. The repository is public, but it is not under a single OSI approved license.
• Head end systems, meter data management, MQTT brokers, RADIUS servers and the integration services between them are ordinary server software built from open source packages.

Every one of those components can carry a known vulnerability. In a FAN, a vulnerable TLS library on the border router undermines the very authentication that keeps the mesh closed. Knowing exactly which versions each border router image and head end service carries is the precondition for patching any of it.

Step by step: a lab Wi-SUN border router, a packet capture and a certificate review

This walkthrough uses the open source Linux border router daemon, wsbrd, from the wisun-br-linux repository. It runs on a Linux host and pairs with a supported radio co-processor development board over UART. It is a lab procedure: do not connect a lab border router to a production mesh or use its example certificates outside the lab, and only transmit on bands and power levels your local radio rules allow.

Step 1: Prepare the host and check the radio device path

Flashing radio co-processor firmware overwrites the board's flash. Follow the vendor's documentation for that step, and before you flash or start the daemon, confirm which serial device is the radio so you do not address the wrong board.

# List serial devices by stable ID before using any of them
ls -l /dev/serial/by-id/
# Confirm the device that appeared when you plugged in the radio board
dmesg | tail -n 20

Step 2: Install dependencies and build

On Debian 13 or a derivative with mbedTLS 3 packaged:

sudo apt-get install libnl-3-dev libnl-route-3-dev libcap-dev \
    libsystemd-dev libmbedtls-dev cmake ninja-build pkg-config lrzsz
git clone https://github.com/SiliconLabs/wisun-br-linux.git
cd wisun-br-linux
cmake -B build -G Ninja .
ninja -C build
sudo ninja -C build install

Record what you just built. Before the box goes anywhere near a pilot, generate an inventory of the packages and libraries in it, because those versions are what you will need to patch later.

git -C wisun-br-linux describe --tags
dpkg -l libmbedtls-dev libnl-3-dev libsystemd-dev | tail -n +6

Step 3: Create a lab PKI

The example directory ships test certificates. Use them to see the daemon start, then replace them with a lab CA you control so you can practise the lifecycle. The exact certificate profile FAN requires is in section 6.5.1 of the member specification; the commands below create an ECDSA P-256 chain suitable for lab practice, not a certified profile.

mkdir -p lab-pki && cd lab-pki
# Lab root CA (keep this key offline in real deployments)
openssl ecparam -name prime256v1 -genkey -noout -out ca_key.pem
openssl req -new -x509 -key ca_key.pem -sha256 -days 7300 \
  -subj "/CN=Lab Wi-SUN Root CA" -out ca_cert.pem
# Border router key and certificate
openssl ecparam -name prime256v1 -genkey -noout -out br_key.pem
openssl req -new -key br_key.pem -subj "/CN=lab-border-router" -out br.csr
openssl x509 -req -in br.csr -CA ca_cert.pem -CAkey ca_key.pem \
  -CAcreateserial -sha256 -days 3650 -out br_cert.pem
chmod 600 ca_key.pem br_key.pem

Step 4: Configure the border router

Copy the example configuration and edit the security relevant lines.

cp -r /usr/local/share/doc/wsbrd/examples .

# examples/wsbrd.conf (lab values)
uart_device = /dev/ttyACM0
user = wisun
group = wisun
network_name = LabFAN
domain = NA
chan_plan_id = 1
phy_mode_id = 0x02
key = lab-pki/br_key.pem
certificate = lab-pki/br_cert.pem
authority = lab-pki/ca_cert.pem
# Shorter lifetimes in the lab so you can watch rotation happen
gtk_expire_offset = 120
pcap_file = /tmp/wisun.pcapng

Valid domain, channel plan and PHY mode combinations depend on your radio; the daemon can list the supported ones. In a real deployment you would point radius_server at your authentication service instead of using the built-in authenticator, and keep a separate CA for each operator domain.

Step 5: Open the firewall for the protocols FAN needs, and nothing more

The README lists the packets that must be allowed. A minimal nftables sketch for the TUN interface:

sudo nft add table inet wisun
sudo nft add chain inet wisun input '{ type filter hook input priority 0; policy drop; }'
sudo nft add rule inet wisun input ct state established,related accept
sudo nft add rule inet wisun input iifname "tun0" icmpv6 type 155 accept   # RPL
sudo nft add rule inet wisun input iifname "tun0" icmpv6 type { nd-neighbor-solicit, nd-neighbor-advert } accept
sudo nft add rule inet wisun input iifname "tun0" udp dport { 546, 547, 10253 } accept  # DHCPv6, EAPOL relay

Add a forward chain that only lets your head end prefix reach the mesh prefix, and keep SSH on a separate management interface.

Step 6: Start the daemon and join a node

sudo wsbrd -F examples/wsbrd.conf -u /dev/ttyACM0

Give a test node a certificate signed by your lab CA, power it on, and watch the log move through discovery, authentication, PAN configuration and routing. Then query the network:

wsbrd_cli --help          # lists the status queries available over D-Bus
ip -6 route show dev tun0
ip -6 neigh show dev tun0

Step 7: Capture and read the traffic

The pcap_file option writes incoming FAN traffic in pcapng format; pointing it at a FIFO lets Wireshark read it live.

mkfifo /tmp/wisun.pcapng
wireshark -k -i /tmp/wisun.pcapng &

Wireshark has a Wi-SUN Field Area Network dissector. Apply the wisun display filter to see Wi-SUN information elements, 6lowpan for compressed headers and icmpv6.type == 155 for RPL control messages. Look for PAN Advertisements and their routing cost, the EAPOL exchange during a join, DIOs from the border router and DAOs from the node.

There is a security detail here worth noticing. The configuration file's comment says secured frames are decrypted before capture and written with the security level field changed to 0. Captures from the border router therefore contain plaintext application data from your meters. Treat those files like production data: store them encrypted, restrict access, and delete them when the test ends.

Step 8: Review certificate handling

Check the chain and fields you are relying on:

openssl x509 -in lab-pki/br_cert.pem -noout -text | \
  grep -E "Issuer:|Subject:|Not After|Public Key Algorithm|ASN1 OID"
openssl verify -CAfile lab-pki/ca_cert.pem lab-pki/br_cert.pem
ls -l lab-pki/*.pem

Then practise the hard parts: revoke the test node and confirm it cannot rejoin; watch the group key lifetime shorten; rotate the border router's own certificate without disturbing joined nodes; and add a second trust anchor to the authority file to simulate a CA migration.

If you have no FAN radio hardware, you can still study the upper layers. The Linux kernel's IEEE 802.15.4 subsystem (the Linux-wpan project) implements 802.15.4 and 6LoWPAN and can create virtual radios for testing, which is enough to watch IPHC compression and IPv6 over a simulated low rate link. It does not implement the Wi-SUN FAN profile, its hopping schedules or its join and key handshakes.

Step 9: Tidy up

Stop the daemon, delete the capture files, and destroy the lab CA key. If the lab border router will be reused, rebuild it from a clean image rather than keeping lab credentials on it.

Common mistakes

• Shipping with example certificates. Test keys and CA certificates in example directories are public. Any border router that still trusts them will authenticate anyone who copies them.
• Treating hopping as encryption. Frequency hopping schedules are advertised in frames. They provide interference resilience and regulatory compliance, not confidentiality.
• Assuming link security is end to end. Group keys protect each hop, and every node in the PAN holds them. If an application needs confidentiality or integrity from meter to head end, add it above IP.
• Putting the border router on a flat network. The neighbor proxy feature can make every meter reachable from wherever the upstream network reaches. Firewall the mesh prefix.
• Ignoring the host to radio link. Keys cross that UART in cleartext unless you encrypt it, and pole top collectors are physically accessible.
• Planning certificate expiry, not revocation. Device certificates that never expire are normal; a revocation process you have never exercised is not.
• One CA forever. A fleet that trusts exactly one anchor has no migration path when that CA is retired or compromised.
• Unsigned or unversioned firmware rollouts. Slow networks tempt teams to skip signing or rollback protection. Both are what make a slow rollout safe.
• No software inventory for border routers and head end services. When a TLS library, DHCP server or broker advisory lands, you cannot patch what you cannot list.

FAQ

What is Wi-SUN FAN used for?

Mostly electricity smart meters, gas and water meters, streetlight controllers and distribution automation equipment. It provides a private, utility owned IPv6 mesh that connects these devices to a head end through border routers.

Is Wi-SUN the same as Zigbee?

No. Both use IEEE 802.15.4 frames, but Wi-SUN FAN uses sub-GHz SUN PHYs with frequency hopping for outdoor multi kilometre links and runs native IPv6 with RPL routing. Zigbee mostly uses 2.4 GHz for short range home and building networks with its own network layer.

What is the difference between Wi-SUN FAN 1.0 and FAN 1.1?

FAN 1.1 adds optional OFDM PHY modes with link rates up to 2.4 Mbit/s, Low Function Nodes for battery devices with long battery life targets, and more frequency bands in the 800 and 900 MHz ranges. The Alliance says 1.1 is compatible with 1.0 networks, though some implementations need configuration to admit FAN 1.0 routers alongside LFNs.

How secure is Wi-SUN?

The design uses 802.1X with EAP-TLS and X.509 device certificates for access control, AES-CCM* frame security on every hop, and group keys that the border router rotates and can revoke. Real risk comes from operations: certificate and CA lifecycle, border router hardening, firmware updates and the software on border routers and head end systems.

Does Wi-SUN use IPv6?

Yes. Every FAN node is an IPv6 host. 6LoWPAN compresses IPv6 headers for the radio, RPL builds routes to the border router, and DHCPv6 assigns global addresses.

What is a Wi-SUN border router?

The node that connects the mesh to the utility's IP network. It acts as the RPL root, keeps source routes for every node, runs or relays authentication, distributes group keys and sets the broadcast schedule.

What frequency does Wi-SUN use in the US?

The Wi-SUN Alliance lists 902 to 928 MHz for North America. Europe uses 863 to 870 MHz and 870 to 876 MHz, and Japan uses 920 to 928 MHz.

Is the Wi-SUN FAN specification public?

FAN 1.1 is available to Contributor and Adopter members. FAN 1.0 can be read without membership as IEEE 2857-2021, and the specification is now also ISO/IEC/IEEE 32857:2026.

Wi-SUN vs LoRaWAN: which should a utility use?

They solve different problems. LoRaWAN suits battery sensors sending small, infrequent uplinks over a star network. Wi-SUN FAN suits dense, mains powered meters and controllers that need IPv6, higher data rates, two way control and a utility owned network. Many utilities run both alongside cellular.

Where Safeguard fits

Safeguard does not monitor Wi-SUN radio traffic, manage device certificates or group keys, run authenticators, configure border routers or scan meter or border router firmware. Nothing in the joining, keying or hardening guidance above depends on it. The honest connection is the software around the mesh: a Linux border router image built from open source libraries, and head end, meter data, MQTT, RADIUS and integration services built from npm, PyPI, Maven, Go modules and container images.

For that software, Safeguard's software composition analysis builds a dependency inventory of the code you own, container scanning lists the package versions inside images (safeguard scan --image <name>), and SBOM generation and analysis records them in SPDX or CycloneDX. The platform shows which projects contain a given component and version, vulnerability matching and reachability analysis help you rank what to fix, and policies and gates can stop a build that pulls a known vulnerable version. When an advisory lands for a TLS library or a DHCP server, the question "which border router images and head end services still ship it" has a quick answer. See using SBOMs to find affected products fast.

Meter and radio co-processor firmware fixes come from the vendor's signed release, delivered over the mesh at the speed worked out above.

Supply chain hygiene still matters for a Wi-SUN deployment even though the radio layer has nothing to do with package managers: border routers link TLS, netlink and DHCP libraries, and every head end and integration service is built from open source components that need the same patch discipline as any web service. The steps below apply to the software you build and ship around the mesh, not to the radios, the keys or vendor firmware, and the fork and patch option they mention is early access today.

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 Wi-SUN radio monitoring or key 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 a border router build directory or at the container images of a head end stack, the same scan lists the packages and versions inside and their known vulnerabilities, so you know which images to rebuild after an advisory.

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 Node.js or Python service that consumes meter reads from a head end.

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 or images ship a given package version, such as the TLS library linked into your border router build, 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

• Wi-SUN Alliance: home page
• Wi-SUN Alliance: Wi-SUN FAN
• Wi-SUN Alliance: Wi-SUN FAN 1.1
• Wi-SUN Alliance: Our Story
• Wi-SUN Alliance: FAQs
• Wi-SUN Alliance: Cyber Security Certificates
• Wi-SUN Alliance: Wi-SUN FAN becomes first wireless mesh network standard adopted by ISO/IEC (7 July 2026)
• Wi-SUN Alliance: Brazil projects surpass 2 million endpoints (1 October 2026)
• IEEE SA: IEEE 2857-2021, Standard for Wireless Smart Utility Network Field Area Network (FAN)
• IEEE SA: IEEE 802.15.4-2020, Standard for Low-Rate Wireless Networks
• RFC 8376: Low-Power Wide Area Network (LPWAN) Overview
• RFC 6282: Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
• RFC 6550: RPL, IPv6 Routing Protocol for Low-Power and Lossy Networks
• RFC 6775: Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks
• RFC 8505: Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network Neighbor Discovery
• RFC 9010: Routing for RPL Leaves
• NIST IR 7628 Rev. 1: Guidelines for Smart Grid Cybersecurity (September 2014)
• wisun-br-linux: Wi-SUN Linux Border Router README
• wisun-br-linux: example wsbrd.conf
• wisun-br-linux: LICENSE
• wisun-br-linux: experimental Wi-SUN Linux router (wsrd) README
• Wi-SUN Alliance: Home Area Networking
• IEEE SA: IEEE 802.1AR, Secure Device Identity
• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• RFC 5216: The EAP-TLS Authentication Protocol
• RFC 7416: A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)
• Wireshark: Display Filter Reference, Wi-SUN Field Area Network
• Linux kernel documentation: IEEE 802.15.4 Developer's Guide
• 3GPP: NB-IoT complete
• Connectivity Standards Alliance: Zigbee

Last reviewed: 24 October 2026. Wi-SUN profiles, certification programs and border router releases change over time; check the pages above for the versions your devices and border routers actually implement.