Time-Sensitive Networking Explained: IEEE 802.1 TSN and Its Security

Time-Sensitive Networking (TSN) is a family of IEEE 802.1 standards that lets ordinary Ethernet carry control traffic with a guaranteed upper bound on latency, very low delay variation and very low loss, while sharing the same cables and switches with everyday IT traffic. It works by giving every device a shared sense of time (IEEE 802.1AS), opening and closing transmit queues on a fixed schedule (IEEE 802.1Qbv), sending critical frames twice over separate paths (IEEE 802.1CB) and policing each stream at the edge (IEEE 802.1Qci). Securing it means protecting the clock, the schedule and the configuration plane as carefully as the data, because a TSN network is usually moving a machine.

That last point deserves to come first. TSN is used in factories, vehicles, aircraft and mobile radio sites, and in industrial settings the frames it carries start motors, stop robots and close valves. A misapplied gate schedule or a shifted clock can halt a production line or make equipment behave in ways nobody planned. Everything in the step by step section of this post assumes a lab or a scheduled maintenance window, with the process owner and the safety engineer involved. Never test on a live machine network to see what happens.

Key takeaways

• TSN is not one protocol. It is a toolbox of IEEE 802.1 standards and amendments for time synchronisation, scheduling, shaping, redundancy, policing and configuration, plus profiles that pick a subset for one industry.
• The IEEE 802.1 TSN Task Group describes its charter as guaranteed packet transport with bounded latency, low packet delay variation and low packet loss. It grew out of the Audio Video Bridging (AVB) task group, and the AVB standards are still part of TSN.
• Time is the foundation. IEEE 802.1AS (generalized PTP, or gPTP) is a profile of IEEE 1588. If the clock is wrong, every time based mechanism on top of it is wrong, so clock integrity is a safety and availability issue, not only an accuracy one.
• The time-aware shaper (802.1Qbv) is a gate control list: a repeating cycle of entries, each saying which traffic classes may transmit and for how long. Linux implements a simplified version in the taprio queueing discipline.
• Frame replication and elimination (802.1CB) sends sequence numbered copies over disjoint paths and discards duplicates near the listener. Per-stream filtering and policing (802.1Qci) stops one misbehaving talker from eating another stream's reserved time.
• Profiles matter: IEC/IEEE 60802 for industrial automation (published 29 June 2026, according to its IEEE project page), IEEE 802.1DG-2025 for in-vehicle networks, IEEE 802.1CM for mobile fronthaul, IEEE 802.1DP-2025 for aerospace and IEEE 802.1BA for audio and video.
• The IETF's Deterministic Networking (DetNet) work carries the same ideas to IP and MPLS. RFC 8655 is the architecture, RFC 9023 covers IP over TSN and RFC 9055 is a full security analysis that applies just as well to TSN.
• The main risks are time attacks, flooding or spoofing of streams, abuse of reservation and configuration protocols, and unauthorised schedule changes. The main defences are segmentation, MACsec where the latency budget allows, strict ingress policing, a locked down management plane and continuous monitoring of clock offset and schedule state.

What problem TSN solves

Best effort Ethernet is fast but not predictable

Standard switched Ethernet is very good at moving a lot of data with a low average delay. What it does not promise is the worst case. When two frames arrive for the same output port at the same moment, one waits. When a queue fills, frames are dropped. A large file transfer that happens to start at the wrong moment can add hundreds of microseconds of queuing delay to a small control frame behind it. For a web page that does not matter. For a motion controller that closes a loop every 250 microseconds, or for an audio stream feeding a mixing desk, it matters a great deal.

Industrial plants solved this for decades with dedicated fieldbuses and with Ethernet variants that change the rules at the physical or data link layer. The cost was separate cabling, separate skills and islands of equipment that could not share infrastructure with the rest of the business. TSN is the IEEE 802.1 answer: keep standard Ethernet frames, standard bridges and standard management, and add mechanisms that let the network make and keep a promise about latency and loss for selected traffic.

What "deterministic" means here

The TSN Task Group page states the goal plainly: deterministic connectivity through IEEE 802 networks, meaning guaranteed packet transport with bounded latency, low packet delay variation and low packet loss. The IETF DetNet architecture (RFC 8655) uses almost the same language and adds the phrase that matters most for planners: the goal is zero congestion loss for reserved flows. Packets may still be lost to bit errors or a cut cable, which is what the redundancy standards address, but they should never be dropped because a queue overflowed.

Deterministic does not mean fast. A TSN network can promise that a frame will arrive within 2 milliseconds every time and still be slower on average than a best effort network that usually delivers in 50 microseconds but sometimes takes 5 milliseconds. Control engineers care about the bound, not the average.

Where TSN came from

TSN began as Audio Video Bridging. The original AVB work started in the IEEE 802.3 Residential Ethernet Study Group and moved to an IEEE 802.1 task group, which produced the credit-based shaper (802.1Qav-2009), the Stream Reservation Protocol (802.1Qat-2010), the first edition of 802.1AS (2011) and the AVB systems profile (802.1BA-2011). The TSN Task Group page confirms that the TSN group "has been evolved from" the AVB task group and that TSN standards include the AVB standards. Secondary accounts date the renaming to 2012; the IEEE page we checked confirms the lineage but does not give the year, so treat 2012 as widely reported rather than confirmed here.

The broadening of scope is the important part. AVB was built for audio and video in studios, venues and cars. TSN widened the target to industrial control, automotive backbones, aerospace and the fronthaul links of mobile networks, which needed tighter bounds, scheduled traffic and redundancy that AVB did not have.

TSN standards timeline

The table below lists the main standards and amendments with the years shown on the IEEE 802.1 TSN Task Group page and, where noted, on IEEE SA standard pages. Many 802.1Q amendments were later rolled into a consolidated revision of 802.1Q (802.1Q-2018, then 802.1Q-2022), so in current documents you will often see them cited as clauses of 802.1Q rather than by amendment name.

Work continues. At the time of writing, the TSN Task Group lists active projects for cut-through forwarding (P802.1DU), a Resource Allocation Protocol (P802.1DD), shaper settings for bursty traffic (P802.1Qdq), enhancements to cyclic queuing and forwarding (P802.1Qdv), source flow control (P802.1Qdw), traffic engineering over wireless (P802.1Qee), optional use of Announce in gPTP (P802.1ASeb) and sequence recovery configuration for 802.1CB (P802.1CBec).

How time synchronisation works: IEEE 802.1AS (gPTP)

Why TSN needs a common clock

Several TSN mechanisms only work if every bridge and end station agrees on the time. A gate control list that says "open the queue for traffic class 7 from 0 to 20 microseconds of every cycle" is meaningless unless the switch at the start of the path and the switch at the end of the path agree on when the cycle starts. Talkers that transmit at a planned offset need the same reference. Listeners that timestamp samples need it too.

What 802.1AS is

IEEE SA describes 802.1AS as the standard for protocols, procedures and managed objects for transporting timing over local area networks, including the transport of synchronised time, the selection of the timing source and the indication of timing impairments. The scope text states that the standard "includes a profile of IEEE Std 1588". The TSN Task Group page adds that the first edition was developed with the IEEE 1588 working group and that its point-to-point 802.3 sublayer is a specific profile of IEEE 1588-2008. Later amendment summaries on the IEEE SA site describe the current text as a profile of IEEE 1588-2019.

The open source Linux TSN documentation project summarises the practical differences well: gPTP is a set of simplifications and constraints on PTP that suit time-sensitive applications, any node in the domain can become grandmaster, and the Best Master Clock Algorithm (BMCA) picks it. For a deeper look at the underlying protocol, see our PTP explainer.

How it measures and corrects time

gPTP uses two exchanges on every link:

1. Peer delay measurement. Each port measures the propagation delay to its direct neighbour with a peer delay request and response that both sides timestamp in hardware. Because every link is measured separately, a bridge knows the delay of each cable it is attached to.
2. Sync and Follow_Up. The grandmaster sends Sync messages; each time-aware bridge receives them, accounts for the link delay and its own residence time, and sends its own Sync downstream. The precise transmit timestamp travels in a Follow_Up message, which is why the reference Linux configuration sets assume_two_step 1.

The LinuxPTP project ships an example configuration for 802.1AS in configs/gPTP.cfg. It is short and worth reading line by line because each setting reflects a gPTP rule:

[global]
gmCapable               1
priority1               248
priority2               248
logAnnounceInterval     0
logSyncInterval         -3
syncReceiptTimeout      3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step         1
path_trace_enabled      1
follow_up_info          1
transportSpecific       0x1
ptp_dst_mac             01:80:C2:00:00:0E
network_transport       L2
delay_mechanism         P2P

A few of those deserve a translation:

• network_transport L2 and ptp_dst_mac 01:80:C2:00:00:0E: gPTP runs directly over Ethernet to a link-local multicast address, not over UDP/IP. Bridges do not forward these frames; each hop terminates and regenerates timing.
• delay_mechanism P2P: peer to peer delay measurement on every link, as described above.
• logSyncInterval -3: a Sync message every 2 to the power of minus 3 seconds, which is 8 per second.
• neighborPropDelayThresh 800: a measured link delay above 800 nanoseconds makes the port treat the neighbour as not capable of gPTP. That is a useful sanity check and also a hint about what an attacker who delays frames would be fighting against.
• transportSpecific 0x1: the value that marks these messages as 802.1AS rather than plain 1588.

Worked example: what a time error does to a schedule

Suppose a production cell runs a 500 microsecond TSN cycle on 1 Gbit/s links and gives the control traffic class a 20 microsecond window at the start of each cycle. If one bridge's clock is 5 microseconds behind the rest, its window opens 5 microseconds late. Frames that arrived on schedule wait 5 microseconds. That is still inside a 20 microsecond window, so nothing breaks. Now let the error grow to 25 microseconds. The late bridge's window no longer overlaps the moment the frames arrive at all, so they wait almost a full cycle, about 475 microseconds, for the next open window. A control loop that budgeted 100 microseconds end to end now misses its deadline every cycle. Nobody had to drop or alter a single frame; shifting one clock was enough. This is why the IETF security analysis (RFC 9055) lists attacks on time synchronisation as a direct route to denial of service for deterministic flows.

Redundant and fault tolerant time

Two recent amendments address resilience. IEEE 802.1ASdm-2024 added hot standby and clock drift error reduction. IEEE 802.1ASed-2026 goes further: according to its IEEE SA summary, it enables fault tolerant timing "by increasing the availability of the time and adding time integrity", using two or more gPTP domains, multiple time distribution paths, the local oscillator and a time selection function. In plain terms, an end station can compare more than one independent source of time and reject a source that disagrees, which is exactly the property you want against both faults and tampering.

How the time-aware shaper works: IEEE 802.1Qbv

Traffic classes, queues and gates

Every 802.1Q bridge port has up to eight traffic classes, each with its own transmit queue. Frames are sorted into classes by their VLAN priority (the 3 bit PCP field) or by other classification. A normal bridge then picks the next frame by strict priority or by a weighted scheme.

802.1Qbv adds a gate in front of every queue. A gate is either open, and frames from that queue may be selected for transmission, or closed, and they may not. A gate control list (GCL) is a list of entries; each entry has a set of gate states and a time interval. The bridge walks the list and repeats it. The total of the intervals is the cycle time. The cycle is anchored to the synchronised clock by a base time, so every bridge in the path can run its own list in step with the others.

The IEEE 802.1 YANG model for scheduled traffic, ieee802-dot1q-sched (the revision in the public YANG models repository is dated 22 October 2023, matching 802.1Qcw-2023), makes the moving parts explicit. It has a gate-enabled switch, an admin-control-list that you write, an oper-control-list that the bridge is actually running, admin-base-time and admin-cycle-time, a config-change-time that says when a pending list will take over, a current-time and a config-pending flag. Two of those, the admin versus operational list and the pending flag, are what you will monitor later.

Protected windows and guard bands

The common design gives scheduled traffic an exclusive window: only the critical class's gate is open, so no other frame can be in flight when the critical frames arrive. The catch is that a frame already being transmitted when a window starts cannot be recalled. To protect the window, bridges stop starting new lower priority frames shortly before it begins, long enough for the largest frame to finish. That idle period is the guard band.

The guard band is the cost of the time-aware shaper. Here is the arithmetic for a 1522 byte maximum frame with a VLAN tag, plus 20 bytes of preamble, start delimiter and interframe gap, so 1542 bytes on the wire:

On a 100 Mbit/s link with a 500 microsecond cycle, a guard band of up to 123 microseconds before each protected window is a quarter of the cycle, which is why frame preemption exists.

Worked example: reading a Linux taprio schedule

Linux implements the time-aware shaper in the taprio queueing discipline. The iproute2 manual describes it as "a simplified version of the scheduling state machine defined by IEEE 802.1Q-2018 Section 8.6.9". Its full hardware offload example is a good worked example:

# From the tc-taprio(8) manual: full offload to a NIC that supports it
tc qdisc add dev eth0 parent root stab overhead 24 taprio \
    num_tc 8 \
    map 0 1 2 3 4 5 6 7 \
    queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 \
    max-sdu 0 0 0 0 0 200 0 0 \
    base-time 200 \
    sched-entry S 80 20000 \
    sched-entry S a0 20000 \
    sched-entry S 5f 60000 \
    flags 0x2

Read it like this:

• sched-entry S 80 20000: for 20,000 nanoseconds, the gate mask is hex 80, binary 1000 0000, so only traffic class 7 may transmit. This is the protected window.
• sched-entry S a0 20000: for the next 20 microseconds, hex a0 is binary 1010 0000, so classes 7 and 5 may both transmit.
• sched-entry S 5f 60000: for 60 microseconds, hex 5f is binary 0101 1111, so classes 0 to 4 and 6 transmit and 7 and 5 wait.
• Cycle time is the sum, 20 + 20 + 60 = 100 microseconds.
• max-sdu ... 200 ... limits class 5 to 200 octet frames, so when classes 5 and 7 share the second window, the most class 5 can delay class 7 is the time of one short frame. That is a guard band made smaller by policy rather than by hardware.
• base-time 200 is in the past, so per the manual, the hardware starts at the next PTP time equal to a whole multiple of 100 microseconds plus 200 nanoseconds.
• flags 0x2 hands the list to the NIC, which runs it from its PTP hardware clock. The manual notes that in this mode the clock is implicitly the NIC's /dev/ptpN, "not necessarily synchronized with the system's CLOCK_TAI". That one sentence explains a large share of real world taprio bugs.

The software mode uses clockid CLOCK_TAI and the kernel's own timer; flags 0x1 enables a txtime assist mode that stamps each frame with its launch time and hands it to the etf qdisc.

What credit-based shaping (802.1Qav) adds

The credit-based shaper predates TSN and still matters. It does not need a schedule. Each shaped class accumulates credit while frames wait and spends it while transmitting, which spreads a stream's frames out instead of letting them leave in bursts. That smoothing is what keeps downstream queues short and makes per hop delay boundable without synchronised gates.

The Linux cbs manual gives the parameters and the formulas from IEEE 802.1Q Annex L, which makes a second worked example easy. Reserve 20 Mbit/s on a 1 Gbit/s port, with a 1500 byte largest interfering frame and a 1500 byte largest frame in the shaped class:

• idleslope = reserved rate = 20,000 kbit/s.
• sendslope = idleslope minus port rate = 20,000 minus 1,000,000 = minus 980,000 kbit/s.
• hicredit = max interfering size times idleslope divided by port rate = 1500 times 20,000 / 1,000,000 = 30 bytes.
• locredit = max frame size times sendslope divided by port rate = 1500 times (minus 980,000) / 1,000,000 = minus 1470 bytes.

Those are exactly the numbers in the manual's example:

# From the tc-cbs(8) manual: 20 Mbit/s reserved on a 1 Gbit/s port
tc qdisc add dev eth0 handle 100: parent root mqprio num_tc 3 \
    map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 \
    queues 1@0 1@1 2@2 \
    hw 0
tc qdisc replace dev eth0 parent 100:4 cbs \
    locredit -1470 hicredit 30 sendslope -980000 idleslope 20000

The manual also warns that idleslope must count the whole frame on the wire, including Ethernet header, frame check sequence and the 20 bytes of layer 1 overhead. Forgetting that overhead is a common reason a "reserved" stream still sees drops.

What frame preemption (802.1Qbu and 802.3br) adds

Frame preemption splits the MAC into an express MAC and a preemptible MAC. When an express frame needs the wire, the port can suspend a preemptible frame mid transmission, send the express frame and then resume the rest of the interrupted frame. The bridge side of this (which classes are express and which are preemptible) is IEEE 802.1Qbu-2016; the Ethernet MAC merge sublayer that carries fragments is defined in IEEE 802.3br.

The point is the guard band. With preemption, the protected window only needs to wait for the smallest piece that cannot be split, not a full maximum length frame. On slower links that recovers a large share of each cycle for best effort traffic.

On Linux, taprio and mqprio accept an fp argument that marks each traffic class as express or preemptible, and the kernel's ethtool netlink interface exposes the MAC merge layer state through the MM_GET and MM_SET messages, including statistics for the preemptible MAC.

Other shapers you will meet

• Cyclic queuing and forwarding (802.1Qch-2017) uses scheduled traffic and per-stream filtering and policing together, as the IEEE SA summary says, so that frames received in one cycle are sent in the next. Latency becomes a simple function of hop count and cycle time.
• Asynchronous traffic shaping (802.1Qcr-2020) shapes per flow without a network wide clock. It came out of work on what contributors called the urgency based scheduler and suits networks where synchronising every bridge is hard.

Shaper comparison

How redundancy and policing work

Frame replication and elimination: IEEE 802.1CB

Rerouting after a failure takes time; even fast protocols take milliseconds to converge, and a control loop can fail in that gap. 802.1CB avoids the gap by never relying on one path. Its IEEE project page describes the scope as identification and replication of frames for redundant transmission, identification of duplicates and elimination of duplicates, and notes there are no other 802 compatible solutions "providing fault tolerance without failover".

In practice it works like this. A talker, or a bridge acting for it, identifies a stream, gives each frame a sequence number and sends copies along two or more disjoint paths. A bridge or listener near the far end runs a sequence recovery function that passes the first copy of each sequence number and discards later duplicates. A single cable or switch failure loses nothing, because the other copy arrives anyway.

RFC 9023, which maps DetNet onto TSN, is a useful public summary of which 802.1CB pieces an implementation needs: a sequencing function, a sequence encode and decode function that carries the number in a Redundancy tag (R-TAG), a stream splitting function and a recovery function, plus stream identification. The identification methods it lists include active destination MAC and VLAN, IP stream identification and mask-and-match identification, the last two coming from the 802.1CBdb-2021 amendment. IEEE 802.1CBcv-2021 added the information model, YANG model and MIB, and the open P802.1CBec project is working on sequence recovery parameter configuration. RFC 9023 also makes a point worth remembering for design: the TSN stream ID and sequence number are not valid outside the TSN sub-network, so an IP router at the border terminates them.

DetNet uses the same idea under a different name. RFC 8655 calls it PREOF, "a collective name for Packet Replication, Elimination, and Ordering Functions", and adds an ordering function that puts packets back in sequence.

Security note on replication

Replication doubles the copies an attacker can see and gives a second place to inject. RFC 9055 lists "increased attack surface" and "header manipulation at elimination routers" as threats. Its analysis of sequence number manipulation describes two outcomes: a changed sequence number can make both replicas get forwarded, which looks like a replay, or it can make both replicas get eliminated, so an attacker with access to only one path can still cause loss of the genuine data. The mitigation is integrity protection on the paths (MACsec or a layer 3 equivalent), ingress policing so only expected talkers can inject into the stream, and monitoring of recovery counters for unexpected rogue or out of window packets.

Per-stream filtering and policing: IEEE 802.1Qci

TSN guarantees break if a talker sends more than it reserved, sends at the wrong time or sends frames it should not send at all. That can be a bug, a misconfiguration, a failing device or an attacker. 802.1Qci-2017 adds a pipeline at bridge ingress that contains the damage:

1. Stream identification and stream filters match incoming frames to a stream and can drop frames above a maximum size.
2. Stream gates open and close on their own schedule, so frames that arrive outside the expected window can be discarded at the first bridge.
3. Flow meters police the rate and burst of each stream and can mark or drop frames that exceed their profile.

Qci is the TSN feature with the most direct security value. It turns "the network trusts every talker to behave" into "the first bridge enforces what each talker reserved". The YANG models for Qci, along with those for scheduled traffic and preemption, were standardised in 802.1Qcw-2023, so policers can be audited through the same management interface as the schedule.

How streams are configured: IEEE 802.1Qcc

Three configuration models

Someone has to decide which streams exist, which path each takes, which gate windows they get and what policers apply. IEEE 802.1Qcc-2018, titled Stream Reservation Protocol enhancements and performance improvements, describes three models:

In the fully centralised model, the CUC collects stream requirements from talkers and listeners (often from the same engineering project that configures the controllers), asks the CNC for a network configuration, and the CNC computes paths, schedules and policers and writes them into bridges. The interface between user side and network side is called the user network interface (UNI).

YANG, NETCONF and RESTCONF

The CNC writes configuration with YANG data models over NETCONF or RESTCONF. The IEEE 802.1 TSN page lists a run of YANG amendments: 802.1Qcp-2018 for bridges, 802.1CBcv-2021 for replication, 802.1Qcw-2023 for scheduled traffic, preemption and Qci, 802.1ASdn-2024 for gPTP, 802.1Qdx-2024 for the credit-based shaper and 802.1Qdj-2024 for TSN configuration enhancements. The published modules are mirrored in the public YANG models repository.

From a security point of view this is the single most important design fact in TSN. Whoever can write to the CNC, or write YANG to a bridge, can change every guarantee in the network. The data plane mechanisms are strong; the configuration plane is ordinary network management, with all the usual weaknesses. Newer and ongoing work adds more protocols in this plane: the Link-local Registration Protocol (802.1CS-2020) and the Resource Allocation Protocol project (P802.1DD).

Profiles: picking features for one industry

A profile selects features, options, defaults and procedures from the TSN toolbox so that equipment from different makers interoperates in one kind of network. The base standards are deliberately broad; profiles are what a buyer can ask for.

Two observations stand out. The automotive profile explicitly brings in the IEEE 802.1 security standards (MACsec, secure device identity, port access control), so security is part of the profile rather than an afterthought. And the industrial profile frames its purpose as convergence: one network for operational technology and other traffic. Convergence is the commercial point of TSN and also the security challenge, because it removes the air gap that separate fieldbuses provided by accident.

How IETF DetNet extends TSN to IP and MPLS

TSN stops at the edge of a bridged layer 2 network. Many deterministic use cases, such as utility substations linked over a wide area network, cross routers. The IETF DetNet working group took the same goals to layer 3.

• RFC 8557 (May 2019) is the problem statement: the needs of several industries for multi-hop paths with deterministic properties.
• RFC 8655 (October 2019) is the architecture, a standards track document. Its abstract lists the techniques: reserve data plane resources along the path, use explicit routes that do not change with topology, and spread a flow's packets over time and space so data survives the loss of a path. It says DetNet "operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time-Sensitive Networking". It splits functions into a service sub-layer (where PREOF lives) and a forwarding sub-layer (where resource allocation and explicit routes live).
• RFC 8938 (November 2020) is the data plane framework and RFC 8939 specifies the IP data plane, which uses existing IP and transport headers to identify flows rather than adding a new encapsulation.
• RFC 9023 (June 2021) covers DetNet IP over a TSN sub-network and, per its abstract, defines no new procedures; it maps DetNet onto the TSN mechanisms described above.
• RFC 9320 (November 2022) gives a timing model and method for computing end to end latency and backlog bounds so control and management planes can promise "bounded latency and zero congestion loss".
• RFC 9055 (June 2021) is the security considerations document, discussed next.

Security: what can go wrong and what to do about it

The threat model in one paragraph

RFC 9055 is written for DetNet but nearly every threat it lists applies to a TSN segment. Its taxonomy covers delay attacks, modification or spoofing of flows, attacks across resource segments (one flow stealing another's reserved resources), attacks on replication and elimination, attacks on the controller plane, reconnaissance, and attacks on time synchronisation. Its opening point is that a deterministic network promises properties a best effort network does not, so it needs protections for those properties on top of normal good practice. An attacker does not need to read or change process data to cause harm; making the right frame arrive late is enough.

Threats and mitigations at a glance

Clock attacks in more detail

Time attacks are the TSN specific risk most worth understanding, and they are conceptually simple. gPTP elects a grandmaster with the BMCA based on advertised clock quality and priority, so a device that falsely advertises a better clock can be elected unless roles are fixed or ports are configured not to accept it. An on path device that delays timing messages in one direction more than the other makes the computed offset wrong by half the asymmetry, which is hard to detect from the protocol alone. And a device that drops timing messages long enough triggers holdover or re-election. The defences are layered: lock roles where the profile permits (the Linux TSN documentation notes that the automotive profile used by some networks disables the BMCA and assigns roles statically), protect links, cross check time against an independent source (802.1ASed formalises this with multiple domains and a selection function), and alert when grandmaster identity, step changes or offset deviate from a baseline.

MACsec: where it fits and what it costs

MACsec (IEEE 802.1AE) provides confidentiality, integrity and data origin authenticity at the link layer; the IEEE SA scope text describes exactly those three properties for frames passed between MAC clients. For TSN it has three practical consequences:

1. It is hop by hop. Each bridge decrypts, forwards and re-encrypts. That matches gPTP's model, where timing is terminated and regenerated on every link, and lets MACsec protect peer delay and Sync messages on each hop. It also means every bridge holds keys and must itself be trusted.
2. It adds latency and bytes. RFC 9055 states the rule for any deterministic network: compute time for cryptography "must be included in the flow latency calculations", so algorithms need bounded worst case execution times. MACsec also adds a security tag and an integrity check value to each frame, which affects the frame sizes used in guard band and shaper calculations.
3. It needs key management. In practice that means the MACsec Key Agreement protocol (part of IEEE 802.1X) and device credentials, ideally IEEE 802.1AR secure device identities. The automotive profile pulls in these security standards explicitly.

Hardware matters here: line rate MACsec with deterministic latency is normally done in the switch or PHY silicon. Software MACsec on a general purpose CPU may not meet the timing budget. For background on the protocol itself see our MACsec explainer.

Segmentation for converged OT and IT

TSN's selling point is that operational and information technology traffic share one network. Security has to keep sharing the wires from turning into sharing trust.

• Separate by VLAN and traffic class, then enforce at the bridge. Critical streams use reserved classes and are policed by Qci. Best effort traffic cannot enter a reserved class because ingress rules rewrite or drop priority markings from untrusted ports.
• Put a filtering boundary between zones. NIST SP 800-82 Revision 3 (the current NIST guide to operational technology security) and the ISA/IEC 62443 approach both describe zones and conduits; a TSN cell is a zone, and anything leaving it should cross a controlled conduit.
• Keep the management plane off the data plane. CNC to bridge NETCONF should run on a separate management VLAN or out of band network, never on the same broadcast domain as office laptops.
• Do not route timing between zones you do not trust. gPTP is link-local by design; keep it that way and do not bridge timing domains into IT networks.

Where the risk really sits: software and firmware

Most real world compromise of an industrial network does not start by forging a gPTP frame. It starts with a reused password on a switch web interface, an unpatched network operating system, an engineering laptop with stale tools, or a CNC or CUC application with a vulnerable library. TSN capable switches run a full network operating system with an embedded web server, SSH, NETCONF agent, SNMP agent and often a container runtime. Those components have the same vulnerability lifecycle as any other software. Our explainer on how a network switch is made covers what is inside that firmware.

Step by step: inventory, lock down and monitor a TSN network

Safety first. Industrial TSN networks control physical machinery. Changing a gate schedule, restarting a grandmaster, enabling MACsec or rebooting a bridge can stop a line or move equipment unexpectedly. Run every step below in a lab or test cell first. On production networks, do read only steps only, during an agreed window, with the process owner and the safety engineer informed. Never run active scans against live controllers, and never push configuration from these examples to production.

Step 1: inventory TSN capable bridges, their features and firmware

Start with what you have. Your CNC or engineering tool usually has the authoritative list of bridges and streams; export it and treat the export as sensitive. Then confirm each bridge's capabilities from the device itself through NETCONF, read only. The YANG library tells you which TSN modules a bridge implements:

# list_tsn_modules.py: read only inventory over NETCONF
# pip install ncclient   (pin the version in requirements.txt)
import sys
from ncclient import manager

TSN_PREFIXES = ("ieee802-dot1q-sched", "ieee802-dot1q-preemption",
                "ieee802-dot1q-psfp", "ieee802-dot1q-stream-filters-gates",
                "ieee802-dot1cb", "ieee1588-ptp", "ieee802-dot1as")

host = sys.argv[1]
with manager.connect(host=host, port=830, username="audit-ro",
                     key_filename="/home/audit/.ssh/tsn_audit_ed25519",
                     hostkey_verify=True, timeout=30) as m:
    for cap in m.server_capabilities:
        if any(p in cap for p in TSN_PREFIXES):
            print(host, cap)

Run it against each bridge's management address with a read only account and host key verification turned on. Record the bridge model, network operating system version, the TSN modules it reports and their revisions. Exact module names vary by revision and by vendor support, so treat the prefix list as a starting point and confirm names against the IEEE published modules.

Then check the firmware version against the vendor's security advisories for that model. Keep the list in your asset inventory alongside the PLCs and drives, not in a separate network spreadsheet. Note any bridge whose firmware is past its support date.

On Linux end stations and gateways, record the NIC driver, whether it has a PTP hardware clock, and whether it supports hardware timestamping:

# Read only checks on a Linux end station
ethtool -i eth0                 # driver and firmware version
ethtool -T eth0                 # timestamping capabilities and PTP Hardware Clock index
tc qdisc show dev eth0          # is taprio, cbs, mqprio or etf configured?
ptp4l -v                        # LinuxPTP version

Step 2: lock down the configuration interface

The TSN guarantees are only as good as the integrity of the configuration that sets them.

1. Isolate management. Put bridge management interfaces and the CNC on a dedicated management VLAN or out of band network. Permit NETCONF (TCP 830) and SSH only from the CNC and a small set of named jump hosts.
2. Turn off what you do not use. Disable HTTP, Telnet, SNMPv1 and v2c, unused RESTCONF endpoints and any default accounts. If the device must offer a web interface, require HTTPS with a certificate you issued.
3. Use keys, named accounts and roles. Separate read only monitoring accounts from accounts that can write schedules. Log every write with the user and source address.
4. Protect the CNC like a controller. The CNC can rewrite every gate list and policer. Patch it, restrict who can log in, back up its database and keep its software inventory current.
5. Control change. Every schedule or policer change should go through the same change process as a PLC program change, with a test in the lab cell first and a rollback plan.
6. Authenticate ports. Use IEEE 802.1X on edge ports where the devices support it, and secure device identities (802.1AR) where available, so an unknown device cannot join a TSN segment by plugging in.
7. Back up golden configurations offline. Export the running schedule, policers and gPTP settings for each bridge after acceptance testing and store them where the network cannot change them.

Step 3: monitor time offset and grandmaster identity

Time is the first thing to watch. On Linux nodes running LinuxPTP, the TSN documentation project describes the reference setup: ptp4l -i eth0 -f configs/gPTP.cfg --step_threshold=1 -m to discipline the NIC clock and phc2sys to discipline the system clock, and it treats an rms offset consistently below 100 nanoseconds as synchronised. To monitor, query the running daemon rather than starting new ones:

# Read only queries to a running ptp4l over its local management socket
pmc -u -b 0 -t 1 'GET TIME_STATUS_NP'     # master_offset, gmPresent, gmIdentity
pmc -u -b 0 -t 1 'GET CURRENT_DATA_SET'   # stepsRemoved, offsetFromMaster, meanPathDelay
pmc -u -b 0 -t 1 'GET PARENT_DATA_SET'    # grandmaster identity and clock quality

Feed those values into your monitoring system every few seconds and alert on:

• grandmaster identity changing to anything outside the approved list;
• absolute offset above a threshold derived from your schedule (for the earlier worked example, well under the 20 microsecond window, for instance 1 microsecond);
• step changes in time, or gmPresent going false;
• a jump in mean path delay on a link that has not been recabled, which can indicate a device inserted in the path.

On bridges, read the gPTP state through the 802.1AS YANG model where supported (802.1ASdn-2024 standardised it) or through the vendor's telemetry, and apply the same alerts.

Step 4: detect schedule drift and unauthorised changes

The time-aware shaper YANG model gives you what you need to verify that each bridge is running the schedule you approved:

<!-- NETCONF get filter for the scheduled traffic state on all interfaces -->
<filter type="subtree">
  <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
    <interface>
      <name/>
      <bridge-port xmlns="urn:ieee:std:802.1Q:yang:ieee802-dot1q-bridge">
        <gate-parameter-table xmlns="urn:ieee:std:802.1Q:yang:ieee802-dot1q-sched"/>
      </bridge-port>
    </interface>
  </interfaces>
</filter>

Compare, per port:

• gate-enabled: is scheduling still on?
• oper-control-list against your golden admin-control-list: is the bridge running what you approved?
• admin-cycle-time and admin-base-time against the plan.
• config-pending and config-change-time: is a new list waiting to take effect, and did you schedule it?

A config-pending value of true with a change time you did not plan is exactly the signal you want to catch before it takes effect. Path names in the filter above follow the IEEE modules; some devices augment different nodes, so check against your bridge's YANG library.

On Linux end stations that run taprio, export the configuration as JSON and diff it against the golden copy:

tc -j qdisc show dev eth0 > /var/lib/tsn-audit/eth0.qdisc.json
diff <(jq -S . /etc/tsn-golden/eth0.qdisc.json) <(jq -S . /var/lib/tsn-audit/eth0.qdisc.json)

Step 5: watch the data plane counters

Finally, monitor the counters that tell you the guarantees are holding:

• Qci stream filter and flow meter discard counters per stream. Any increase means a talker sent something it should not have, or a reservation is too tight.
• 802.1CB sequence recovery counters for lost, out of order and rogue packets.
• Queue drop counters in reserved traffic classes, which should be zero by design.
• MAC merge statistics on preemption capable links (on Linux, through the ethtool netlink MAC merge interface).

Baseline them during acceptance tests, then alert on change.

Common mistakes

• Treating TSN as one switch feature. Buying a "TSN switch" says little. Ask which standards, which profile and which YANG modules it supports, and test interoperability with your end stations.
• Mixing clocks on Linux. The taprio manual is explicit that in full offload mode the schedule runs from the NIC's PTP hardware clock, which is not necessarily synchronised with CLOCK_TAI. Run phc2sys and check offsets before blaming the network.
• Forgetting layer 1 overhead. The cbs manual reminds you to count headers, frame check sequence and the 20 bytes of preamble and gap. Reservations computed on payload alone are too small.
• Ignoring guard bands on slow links. At 100 Mbit/s a full size frame takes over 120 microseconds. Without preemption or a max SDU limit, short cycles leave little room for anything else.
• Leaving the grandmaster election open. If any port can win the BMCA, any device can become your clock. Fix roles where the profile allows and alert on grandmaster changes.
• Skipping Qci. Without ingress policing, a single faulty or compromised talker can break guarantees for others on the same path.
• Putting the CNC on the office network. The configuration plane is the highest value target in a TSN network.
• Enabling MACsec without redoing the latency budget. Extra bytes per frame and processing time change guard bands and shaper parameters.
• No golden configuration. Without an approved baseline you cannot tell drift from a legitimate change.
• Testing on production. Industrial TSN networks move machinery. Use a lab cell.

FAQ

What is Time-Sensitive Networking in simple terms?

It is a set of IEEE 802.1 standards that makes standard Ethernet able to promise a maximum delay and near zero loss for selected traffic, while other traffic shares the same network. It does that with synchronised time, scheduled transmit gates, shaping, redundancy and per-stream policing.

Is TSN the same as AVB?

No, but it grew from it. The IEEE 802.1 TSN Task Group page says the group evolved from the Audio Video Bridging task group and that TSN standards include the AVB standards. AVB focused on audio and video; TSN added scheduled traffic, redundancy, policing and centralised configuration for industrial, automotive and other uses.

What is the difference between 802.1AS and IEEE 1588 PTP?

802.1AS is a profile of IEEE 1588. It constrains PTP for time-sensitive networks: it runs over layer 2 to a link-local address, measures delay on every link with peer delay messages, and every time-aware bridge regenerates timing on each hop.

What does 802.1Qbv actually do?

It adds a gate to each egress queue and a repeating gate control list that opens and closes those gates at set times in a cycle, anchored to synchronised time. Critical traffic gets windows in which nothing else can transmit, which gives very low and predictable delay.

Do I need frame preemption if I have 802.1Qbv?

Not always. On fast links with short guard bands the time-aware shaper alone may be enough. On slower links, or where long best effort frames share the port, preemption (802.1Qbu with 802.3br) shrinks the guard band and returns bandwidth to other traffic.

Does TSN encrypt traffic?

No. The TSN mechanisms provide timing, scheduling and reliability, not confidentiality or authentication. Those come from IEEE 802.1 security standards such as MACsec (802.1AE), port access control (802.1X) and secure device identity (802.1AR). The automotive profile, 802.1DG-2025, explicitly builds on those security standards.

How does TSN relate to DetNet?

TSN is layer 2 and works within a bridged network. IETF DetNet applies the same goals at layer 3 over IP and MPLS, as described in RFC 8655. RFC 9023 describes DetNet IP running over a TSN sub-network.

What is the biggest security risk in a TSN network?

In practice, the configuration plane: the CNC and the management interfaces of bridges. Whoever can write schedules and policers controls every guarantee. Time synchronisation is the biggest protocol level risk, because shifting a clock can make traffic miss its windows without touching a single data frame.

Can I run TSN on Linux?

Yes, for end stations and lab bridges with suitable NICs. Linux provides taprio for the time-aware shaper, cbs for the credit-based shaper and etf for launch time, and LinuxPTP provides ptp4l, phc2sys and pmc for 802.1AS. Hardware offload depends on the NIC and driver.

What is IEC/IEEE 60802?

It is the TSN profile for industrial automation, a joint IEC and IEEE dual logo standard. Its IEEE project page lists it as published on 29 June 2026. It selects TSN features, options and defaults for bridges and end stations so that industrial devices from different makers can share a converged network.

Where Safeguard fits

Safeguard's fit here is indirect, and it is better to say so plainly. Safeguard does not configure TSN networks, monitor gPTP, analyse switch firmware or inspect industrial traffic. What it does is software supply chain security for code your team builds and ships. In a TSN deployment that often includes the CNC or CUC application if you build or extend it, gateway and edge applications that move data between the TSN cell and the rest of the business, monitoring collectors written in Python or Go, the container images those run in and the Linux user space on end stations. Safeguard can scan those repositories, container images and SBOM files, show which projects contain a given component and version, match them against vulnerability data, rank findings by reachability and, when a fixed version exists, open a pull request to upgrade it. Switch operating systems and NIC firmware still have to be updated through their vendors.

A TSN deployment depends on far more open source than the switches suggest: LinuxPTP, iproute2 and kernel drivers on end stations, NETCONF and YANG libraries in configuration tools, and many Python and Go packages in the gateways and collectors around the cell. When one of those dependencies has a known vulnerability, the steps below cover the parts you build yourself, while the bridges and NICs still follow their vendors' update path.

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 TSN configuration, clock monitoring or industrial network security. 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 repository for a CNC extension, a TSN monitoring collector or an edge gateway image 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 dashboard or collector that reads gPTP offsets and schedule state from your bridges.

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, for example a NETCONF client library used by your configuration tooling, and get the answer from your own scan data.

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

Quick check

Sources

• IEEE 802.1 Time-Sensitive Networking (TSN) Task Group
• IEEE 802.1: IEC/IEEE 60802 TSN Profile for Industrial Automation
• IEEE 802.1: P802.1DG TSN Profile for Automotive In-Vehicle Ethernet Communications
• IEEE 802.1: 802.1CM Time-Sensitive Networking for Fronthaul
• IEEE 802.1: 802.1CB Frame Replication and Elimination for Reliability
• IEEE 802.1: 802.1AE MAC Security (MACsec)
• IEEE SA: IEEE 802.1AS-2020
• IEEE SA: IEEE 802.1Qbv-2015
• RFC 8557: Deterministic Networking Problem Statement
• RFC 8655: Deterministic Networking Architecture
• RFC 8938: DetNet Data Plane Framework
• RFC 8939: DetNet Data Plane: IP
• RFC 9023: DetNet Data Plane: IP over IEEE 802.1 TSN
• RFC 9055: DetNet Security Considerations
• RFC 9320: DetNet Bounded Latency
• tc-taprio(8) manual page
• tc-cbs(8) manual page
• Linux kernel documentation: ethtool netlink interface (MAC merge)
• TSN Documentation Project for Linux
• TSN Documentation Project for Linux: Synchronizing Time with Linux PTP
• TSN Documentation Project for Linux: Configuring TSN Qdiscs
• LinuxPTP project
• LinuxPTP gPTP.cfg example configuration
• IEEE 802.1 YANG module ieee802-dot1q-sched (YANG models repository)
• NIST SP 800-82 Rev. 3: Guide to Operational Technology Security

Last reviewed: 24 October 2026. Several TSN amendments are still in progress and IEEE pages are updated by project editors; check the IEEE 802.1 TSN page for the current edition of each standard before citing a clause or year.