Fibre Channel Explained: Fabrics, Zoning, FC-SP and SAN Security

Fibre Channel is a dedicated, lossless network built to carry storage traffic, mostly SCSI and NVMe commands, between servers and disk arrays. Its standards come from the INCITS Fibre Channel technical committee, long known as T11. A Fibre Channel storage area network is secured mainly by zoning and LUN masking, which control access, and by FC-SP, which adds real authentication and encryption.

That distinction is the one most teams blur. Zoning works as long as every device tells the truth about its name; it was never designed to stop a device that lies. FC-SP adds cryptographic checks, membership policies and frame encryption, but it is optional and many fabrics still run without it. This post explains how a fabric works, what each control enforces, and how to inventory and harden a Linux host on a fabric. It is a companion to our explainers on iSCSI and NVMe over Fabrics, which cover the Ethernet based alternatives, and to our guide to a home NAS with ZFS for the file storage side.

Key takeaways

• Fibre Channel standards come from the INCITS Fibre Channel committee, called INCITS/T11 until January 2022.
• The stack has five levels, FC-0 to FC-4. An FC-2 frame has a 24 octet header and a data field of up to 2112 octets.
• Nearly every modern SAN is a switched fabric, usually two separate fabrics for redundancy.
• Every port has a 64 bit World Wide Name and gets a 24 bit N_Port_ID at Fabric Login (FLOGI), then registers with the name server and opens sessions with Port Login (PLOGI).
• The FCIA roadmap lists 128GFC as technically complete in 2022 with products in 2024, and 256GFC as technically complete in 2025.
• Zoning and LUN masking are access control built on names a device asserts, not names it proves.
• FC-SP adds DH-CHAP and certificate authentication, signed fabric membership policies and ESP_Header frame protection. NIST SP 800-209 recommends authenticating every host and switch before it joins.

What is Fibre Channel, and who standardises it?

Fibre Channel is a serial transport for moving blocks of data between computers and storage with very low loss. RFC 5324 calls it "logically a bidirectional point-to-point serial data channel" that can carry many higher level protocols. In practice it carries SCSI (through FCP, the Fibre Channel Protocol) and, more recently, NVMe.

The standards come from a committee of INCITS, the ANSI accredited InterNational Committee for Information Technology Standards. Its page records a naming change: the committee was "formerly known as INCITS/T11 until January 2022", and the T11 label is still widely used. The old t11.org address now redirects there.

The standards are a family of documents with short names:

Each family has numbered editions (FC-GS-5, FC-SP-2 and so on); RFC 4936, for example, cites FC-GS-5 as ANSI INCITS 427-2007. The INCITS documents are sold, so most engineers learn the protocol through IETF summaries, Linux kernel documentation and vendor manuals. A separate body, the Fibre Channel Industry Association (FCIA), runs interoperability plugfests and publishes the speed roadmap but does not write the standards.

Why do data centres still run Fibre Channel alongside Ethernet storage?

Ethernet block storage, first iSCSI and now NVMe over TCP, has taken most new small and mid sized deployments. Fibre Channel survives in large enterprises, banks, hospitals and government data centres for concrete reasons:

• It is a separate network by construction. A fabric carries no user traffic and does not route to the internet. NIST SP 800-209 draws exactly this line between storage on shared networks and dedicated storage networks.
• It is lossless by design. Credit based flow control means a port sends a frame only when the receiver has advertised a free buffer. FCoE needs Data Center Bridging to make Ethernet behave the same way, which is why the Linux FCoE tools include a monitor for the DCB daemon.
• Fabric services are built in. Name lookup, zoning and change notification are part of the standard.
• The investment is long lived. FCIA states that each speed generation stays backward compatible with at least the two before it.

The costs are dedicated switches, optics, host bus adapters (HBAs) in every host and specialised skills, which is why greenfield storage mostly goes over Ethernet.

How is the Fibre Channel stack layered?

The standards describe Fibre Channel in five levels. RFC 4338 explains the two that matter most: FC-2 defines the frame format and transport services, and FC-4 carries upper level protocols such as SCSI.

Frames, classes and addresses

RFC 4338 describes the FC-2 frame as a start of frame delimiter, a 24 octet header (destination ID, source ID, type and control fields), a data field of 0 to 2112 octets that may begin with optional headers, a 4 octet CRC and an end of frame delimiter. The optional headers are ESP_Header, Network_Header, Association_Header and Device_Header. ESP_Header is how FC-SP protects frames. Frames form sequences (one information unit, such as a SCSI command), and sequences form exchanges (one complete operation, such as a read).

The start delimiter selects a class of service. RFC 4338 lists Classes 1, 2, 3, 4 and 6 and notes that Classes 3 and 2 are the common choices for storage. Almost all storage traffic is Class 3, an unacknowledged datagram service: the upper layer retries on error, and credit based flow control keeps loss low.

Every frame carries 24 bit source and destination addresses. RFC 4936 explains that each octet is a level in a hierarchy with the Domain_ID (one per switch) at the top; the usual reading is Domain, Area, Port. Addresses at the top of the space belong to fabric services. The Wireshark dissector lists them: 0xFFFFFE is the F_Port server (target of Fabric Login), 0xFFFFFD the fabric controller, 0xFFFFFC the directory (name) server, 0xFFFFFA the management server and 0xFFFFFF broadcast.

Topologies

RFC 4338 lists three topologies:

The Linux FC transport reports which topology a host port uses in its port_type attribute, with values such as "NPort (fabric via point-to-point)", "LPort (private loop)" and "NPIV VPORT". Modern designs build two independent fabrics, A and B, with every host and array attached to both, so one mistake takes down half the paths rather than all of them.

What are WWNs, N_Ports, F_Ports and E_Ports?

Port types

RFC 4936 and RFC 5324 give the same concise glossary of port names, which every switch interface and error message uses.

E_Ports are the most security sensitive ports on a switch: an E_Port that comes up merges the neighbour, and its view of zoning, into your fabric.

World Wide Names

RFC 4338 says Fibre Channel entities are identified by non volatile 64 bit Name_Identifiers whose top 4 bits select the format; common formats embed the manufacturer's IEEE identifier. They are written as eight hex bytes, for example 20:00:00:25:b5:aa:00:01, or as one hex number in Linux sysfs. A port's name is its WWPN (N_Port_Name), the name zoning and masking normally use. A node's name is its WWNN, shared by all its ports. Switch ports and the fabric itself also have names.

Each port also gets a volatile 24 bit N_Port_ID at login, which can change when a cable moves.

The critical point for security is that a WWN is a label, not a credential. A port states its name at login and nothing in basic Fibre Channel proves the claim. The Linux FC transport documentation describes N_Port ID Virtualization (NPIV) virtual ports, where one HBA port logs in several times under different names, and notes that a management utility "would be responsible for creating wwpn/wwnn's for the vport". Port names can be chosen by software. That is a legitimate feature for virtual machines, and it is why NIST SP 800-209 discusses "WWN spoofing attacks".

How login works: FLOGI, name server, PLOGI, PRLI

A host port coming up on a fabric goes through a fixed sequence of Extended Link Service (ELS) and Common Transport (CT) requests. Wireshark's ELS definitions give the codes: PLOGI 0x03, FLOGI 0x04, LOGO 0x05, PRLI 0x20, FDISC 0x51, RSCN 0x61, SCR 0x62 and AUTH 0x90.

RFC 4338 sums up the two logins: FLOGI gets the port an N_Port_ID and negotiates parameters such as frame size, and PLOGI "provides each Nx_Port with the other Nx_Port's N_Port_Name". The name server, which RFC 4438 says lets ports "register and discover Fibre Channel attributes", is distributed across every switch, so any switch gives a fabric wide answer.

FC-SP authentication slots into this sequence. FCIA explains that a port sets a security bit in its login parameters, the peer echoes it if it agrees, and an AUTH_ELS negotiation runs in the clear to pick algorithms before the cryptographic exchange. If both sides require security and cannot agree, the link stays down unless the audit mode introduced in FC-SP-3 is on.

How switches join: inter switch links and FSPF

When two switches connect through E_Ports they assign Domain_IDs, merge zoning databases and route with Fabric Shortest Path First (FSPF), a link state protocol whose management objects RFC 4626 defines. A new switch with a permissive or conflicting zoning configuration can segment the fabric or import its configuration, which is what FC-SP membership policies prevent. RFC 5324 also describes Virtual Fabrics (FC-SW-4), which tag each frame with a virtual fabric ID and give each virtual fabric its own name server and zoning, a stronger separation than zones.

Carrying Fibre Channel over IP: FCIP and iFCP

RFC 3821 (July 2004) defines Fibre Channel over TCP/IP (FCIP), which tunnels frames between fabric islands over TCP on well known port 3225; RFC 4172 defines iFCP, a gateway approach that saw far less use. RFC 3821 says an FCIP entity "MUST implement portions of the IPsec protocol suite". Implemented is not enabled: check that replication links actually run IPsec, because traffic leaving the building is where physical isolation stops applying.

How have Fibre Channel speeds evolved, and what is FC-NVMe?

Speeds are named by generation ("GFC"). The FCIA speed roadmap (Speedmap version 24, updated July 2023) lists the year each T11 specification was technically complete and the year products reached the market.

The roadmap's throughput figures are both directions combined. The older 1GFC, 2GFC and 4GFC generations are not in the current table. A separate inter switch link table lists multi lane links: 10GFC (spec 2003, products 2009), 128GFC over four 28.05 GBaud NRZ lanes (2014, 2016) and 256GFC over four 28.9 GBaud PAM-4 lanes (2018, 2020). So "128GFC" names both a four lane ISL from 2016 and a single lane port from 2024; check which one a data sheet means.

PAM-4 carries two bits per symbol where NRZ carries one, which is how 64GFC doubled throughput at almost the same baud rate, at the cost of more sensitivity to noise.

What is FC-NVMe?

NVMe is the command set built for flash, with many parallel queues. NVM Express says NVMe over Fabrics 1.0, released in June 2016, extended NVMe "to additional transports beyond PCIe, such as Ethernet, Fibre Channel, Infiniband and RDMA". FCIA lists FC-NVMe among the current FC-4 mappings alongside FCP. On a fabric it is just another FC-4 type: zoning applies exactly as for SCSI and one HBA carries both, which makes it the lowest friction route to NVMe for an existing Fibre Channel shop.

In Linux, the kernel's NVMe FC transport addresses ports as nn-0x<16 hex digits>:pn-0x<16 hex digits>, node name then port name. The nvme-cli documentation lists fc as a transport alongside rdma, tcp and loop, currently marked "experimental" in that tool; most FC-NVMe connections are made automatically by the HBA driver and udev rules.

Security can sit at two layers: FC-SP at the Fibre Channel layer, or NVMe in band authentication (DH-HMAC-CHAP), which the Linux kernel implements as "NVMe over Fabrics In-Band Authentication" and nvme-cli exposes through --dhchap-secret and --dhchap-ctrl-secret. Whether your array and HBA support either on Fibre Channel is a question for their documentation; do not assume that what works over NVMe/TCP works over FC.

What are zoning and LUN masking?

Zoning

RFC 4936, the IETF management information base for the Fibre Channel zone server, gives the cleanest definition: zones "provide a mechanism to control frame delivery between Nx_Ports ('Hard Zoning') or to expose selected views of Name Server information ('Soft Zoning')", and "communication is only possible when the communicating endpoints are members of a common zone".

RFC 4936 lists five ways to specify zone membership: the device's N_Port_Name (WWPN), its N_Port_ID, its Node_Name, the F_Port_Name of its switch port, or the switch Domain_ID and physical port number. In practice nearly every fabric uses WWPN zoning, port zoning (written domain,port) or a mix.

Zones are grouped into zone sets. RFC 4936 says only one zone set "may be activated at one time", and activation applies "as a single entity across all Switches in a Fabric". The usual workflow is to copy the active zone set, edit, review and activate, which replaces the whole active configuration fabric wide in one step. Activating the wrong zone set is a classic cause of whole fabric outages. Enhanced zoning, defined in FC-GS-5, wraps changes in a server session that locks the zoning database so two administrators cannot overwrite each other; RFC 4936 notes it works only when every switch supports it.

The default zone

Ports not in any zone of the active zone set fall into the default zone, whose setting is permit or deny. With permit, every unzoned port can talk to every other unzoned port. RFC 4936 gives its default zone object a default value of deny, and NIST SP 800-209 recommendation AC-SS-R26 says it "should always be configured as 'deny all'". A reset switch, or a fabric with zoning disabled and a permissive default, can expose every array to every host.

Hard zoning and soft zoning: the terms mean two different things

The same words are used for two separate ideas.

The IETF definition, in RFC 4936 and RFC 5324, is about enforcement. Hard zoning "is enforced in the Fabric (i.e., switches)" by filtering frames. Soft zoning is "enforced at the endpoints" by "relying on the endpoints to not send traffic to an N_Port_ID not obtained from the Name Server". A well behaved HBA never reaches a device it was not told about; a badly behaved one can.

NIST SP 800-209 (NC-SS-R7) uses the terms for membership type: soft zoning means zoning by host WWN, whose weakness is that ports may be reached "if the user in another zone correctly guesses the Fibre-Channel address", and hard zoning means zoning by "physical port numbers on SAN switches", which "protects from WWN spoofing attacks". Many switches enforce WWN zones in hardware, which is hard in one sense and soft in the other. So ask two questions:

NIST says WWN zoning may be preferable where the SAN spans facilities with weaker physical security, and port zoning where physical access is thoroughly protected. Membership by both WWPN and port, where supported, gets most of both. NIST also recommends a blended approach across host, switch and storage controls (NC-SS-R3) and separating zones by environment, traffic type, host type and device type (AC-SS-R27).

Single initiator zoning

The common pattern is single initiator zoning: one host port plus the array ports it needs per zone. Peer zoning, also called target driven zoning, lets one principal (usually an array port) talk to many members that cannot talk to each other. Both limit security exposure and noise: when a port logs in or out, the fabric sends RSCNs to every port sharing a zone with it, so a big zone makes every host react to every other host's link flap.

LUN masking

Zoning decides which ports can talk; LUN masking decides which volumes an array presents to which host WWPN. A host not in the mapping sees no LUNs even if zoned to the array port. NIST SP 800-209 says to mask "as close to the data as possible" (NC-SS-R4), restrict both zoning and masking to "the minimum required access" (AC-SS-R24), and apply the same to snapshots and replicas, which a host with access to a device often should not get (AC-SS-R25). Host side filtering in the HBA driver, operating system and volume manager is a third layer.

Why zoning and LUN masking are access control rather than security

All of these controls work from identity claims that nothing checks cryptographically:

• A WWPN is whatever the port presents. Someone with root on a host that has an HBA, or with their own device on the fabric, may be able to present a WWPN that is zoned and masked to sensitive volumes.
• Port zoning trusts whoever is plugged into a port.
• Soft zoning, in the IETF sense, trusts the host to follow the name server.
• Nothing in the base protocols encrypts data. FCIA describes the cases: tapping fibre between buildings, an insider at a patch panel, or a switch in the path recording traffic.
• Switch administrators can change zoning for the whole fabric, and NIST lists compromise of an FC SAN fabric as an incident response scenario (IR-SS-R1).

Zoning still prevents the commoner failure, the wrong volume reaching the wrong host, which RFC 4936 lists as an aim. It is a lock that assumes everyone on the fabric is honest. FC-SP is the part that does not.

What do FC-SP, FC-SP-2 and FC-SP-3 add?

FC-SP is the Fibre Channel Security Protocols standard. RFC 5324, published in September 2008 to define SNMP management objects for it, summarises its four parts: protocols to authenticate Fibre Channel entities, protocols to set up session keys, protocols to negotiate frame by frame integrity and confidentiality, and protocols to establish and distribute security policies across a fabric. FC-SP-2 is the second edition and is the version NIST SP 800-209 cites. FC-SP-3 is the newest edition, which FCIA describes as a recent INCITS standard with changes aimed at quantum resistance and an audit mode.

Authentication: DH-CHAP, FCAP, FCPAP and IKEv2-AUTH

RFC 5324 explains that authentication can run switch to switch, node to switch and node to node, and that the defined protocols "are able to perform mutual authentication with optional shared key establishment". There are three credential models and four protocols.

DH-CHAP is the CHAP idea used by iSCSI with a Diffie-Hellman step added, which makes replaying or guessing from a captured exchange much harder than with plain CHAP. It is still a shared secret scheme, so secret length and uniqueness per device matter. All of this rides in AUTH_ELS frames (ELS code 0x90) right after FLOGI or PLOGI, before any data.

NIST SP 800-209 recommends that "every host and storage switch should have a unique identity and should be authenticated before joining the network (e.g., FC-SP-2 AUTH-A)" (NC-SS-R1), and that switch certificates come from an organisation approved PKI, for example with FCAP, "rather than the devices' self-signed certificates" (NC-SS-R2).

Security associations and ESP_Header

Authentication proves who is on the other end; frame protection keeps traffic from being read or altered. RFC 4595 (July 2006) defines how FC-SP uses IKEv2 to negotiate protections, and RFC 5324 calls the result the Security Association Management protocol, "a subset of the IKEv2 protocol suitable for Fibre Channel", stressing that it "is not IPsec". Security associations come in pairs, one per direction, with traffic selectors deciding what each protects. Two protections exist:

• ESP_Header protects FC-2 frames. RFC 4595 says it provides "origin authentication, integrity, anti-replay protection, and confidentiality" with an encapsulation equivalent to IPsec ESP, and its authentication covers the whole FC-2 header. This is what vendors usually call in flight encryption.
• CT_Authentication protects Common Transport requests, which carry name server and zone server operations, the messages that configure a fabric.

RFC 4338 adds that soft zoning does not work for IP over Fibre Channel, which bypasses the name server, and that ESP_Header can protect that traffic instead.

Fabric policies

The other half of FC-SP is policy. RFC 5324 describes fabric wide policy objects: a Policy Summary Object listing the active objects, each paired with a cryptographic hash so switches can check they enforce the same thing; a Switch Membership List of switches allowed in the fabric; a Node Membership List of nodes allowed to connect; an IP Management List of hosts allowed to manage the fabric; per switch Switch Connectivity Objects restricting what each switch may connect to; and Attribute Objects for extensions.

Changes follow the same edit then activate model as zoning, and FC-SP defines an FC-SP Zoning variant managed separately. NIST SP 800-209 asks you to use an allow list "of switches, arrays, and hosts that can join the fabric" (AC-SS-R29) and to limit which switches may communicate (NC-SS-R9). Membership lists stop a rogue switch on an E_Port from merging into your fabric.

FC-SP-3: audit mode and the quantum question

FCIA articles published in April and October 2026 describe FC-SP-3 as the recent INCITS edition, responding to the NSA's CNSA 2.0 guidance and to EU encryption requirements in NIS2 and DORA, with "harvest now, decrypt later" attacks as the motivation for quantum resistance. FCIA also describes an audit mode introduced in FC-SP-3: when two ports cannot agree on security, policy can keep the link up and raise an alert instead of failing it. That is the right way to roll out authentication on a busy fabric: audit, fix every port that would fail, then enforce. We could not access the FC-SP-3 text, which INCITS sells, so we have not verified its algorithm list.

What is actually deployed in practice?

Honest answer: it varies, and we found no public data on deployment rates. Some signals:

• Switch to switch DH-CHAP is the simplest FC-SP feature to adopt, because it involves only switches the storage team controls.
• Host to switch authentication needs HBA firmware, driver and switch support plus secret management for every host, and is less common.
• Frame encryption needs support on both ends of each path. The in tree Linux qla2xxx driver contains an implementation it calls EDIF, in which a user space authentication application registers with the driver, sessions re login with a secure flag, and security associations are installed once the application reports success. FCIA describes HBAs that ship with certificates created at manufacture and suggests key refresh, for example every seven days.
• Fabric membership policies, where your switches offer them, are the cheapest high value control to turn on.

Ask which features each firmware version supports, which need a licence, and which are enabled today.

How do Fibre Channel, FCoE, iSCSI and NVMe/TCP compare?

Fibre Channel's main security advantage is structural isolation, not its optional protocol security.

Step by step: inventory a Linux host on a fabric, review zoning, enable authentication and log changes

This walkthrough assumes a Linux host with one or more Fibre Channel HBAs and a switched fabric. The commands read state. Nothing here writes to a disk. Where a step could disrupt I/O, there is a warning.

Step 1: list the host's Fibre Channel ports

The kernel's FC transport class exposes each HBA port as /sys/class/fc_host/hostN.

# List FC host ports
ls /sys/class/fc_host/

# Print the key attributes for each port
for h in /sys/class/fc_host/host*; do
  echo "== $(basename "$h")"
  for a in port_name node_name port_id port_type port_state speed \
           supported_speeds fabric_name symbolic_name; do
    printf '  %-17s %s\n' "$a" "$(cat "$h/$a" 2>/dev/null)"
  done
done

What to look for: port_name is the WWPN that zoning and masking use; port_state should be Online; port_type should be NPort (fabric via point-to-point); port_id is the N_Port_ID, whose first byte is the switch Domain_ID. fabric_name should differ between the port cabled to fabric A and the port cabled to fabric B. If both show the same name, your redundant fabrics are one fabric.

Some drivers also expose firmware_version, driver_version, model and serial_number. Record them for the firmware plan in step 8.

for h in /sys/class/fc_host/host*; do
  for a in model firmware_version driver_version serial_number; do
    [ -r "$h/$a" ] && printf '%s %-17s %s\n' "$(basename "$h")" "$a" "$(cat "$h/$a")"
  done
done

Warning: the same directory has a write only file, issue_lip. Writing to it reinitialises the link and interrupts I/O on that path. Never write to it during an inventory; if you ever need it, first confirm healthy multipath paths on the other fabric.

Step 2: list the remote ports this host can see

Every port the host has logged into appears as a remote port with node_name, port_name, port_id, roles and port_state, as the kernel documentation lists.

for r in /sys/class/fc_remote_ports/rport-*; do
  printf '%-18s wwpn=%s id=%s roles="%s" state=%s\n' \
    "$(basename "$r")" "$(cat "$r/port_name")" "$(cat "$r/port_id")" \
    "$(cat "$r/roles")" "$(cat "$r/port_state")"
done

With single initiator zoning you should see only target roles, never another host's initiator port. An unexpected remote port means a zone holds more than it should or the default zone is permit.

Step 3: map ports to block devices

# Show disks with their transport, SCSI address and WWN
lsblk -d -o NAME,SIZE,TRAN,HCTL,WWN,VENDOR,MODEL

# Persistent paths that encode the host port and target WWPN
ls -l /dev/disk/by-path/ | grep -i fc

# If multipath is in use, show each LUN and its paths
multipath -ll

TRAN shows fc for Fibre Channel disks, by-path names include the target WWPN and LUN, and multipath -ll should show paths through both fabrics.

For FC-NVMe namespaces:

nvme list-subsys

Each controller line shows the transport fc and an address in the form traddr=nn-0x...:pn-0x...,host_traddr=nn-0x...:pn-0x....

Step 4: build an inventory file and diff it

Turn this into a file you can diff on every attached host and compare with what zoning and masking say should exist.

#!/usr/bin/env bash
# fc-inventory.sh: print one line per (local port, remote port) pair
set -euo pipefail
host="$(hostname -s)"
for h in /sys/class/fc_host/host*; do
  hn="$(basename "$h")"
  lw="$(cat "$h/port_name")"
  fab="$(cat "$h/fabric_name")"
  for r in /sys/class/fc_remote_ports/rport-"${hn#host}":*; do
    [ -e "$r" ] || continue
    echo "$host,$hn,$lw,$fab,$(cat "$r/port_name"),$(cat "$r/roles" | tr ',' ' '),$(cat "$r/port_state")"
  done
done | sort

# Run daily and keep history
./fc-inventory.sh > "fc-$(date +%F).csv"
diff fc-"$(date -d yesterday +%F)".csv fc-"$(date +%F)".csv || echo "FC view changed"

Any change is either a planned zoning change or something to investigate.

Step 5: review zoning on the switches

Switch commands differ by vendor, so this step lists what to check. Export the active zone set from each fabric to a text file and keep it in version control. Then check:

1. Default zone is deny. Matches NIST AC-SS-R26.
2. Zoning is enabled and a zone set is active on every fabric.
3. Single initiator zones, unless a peer zone or cluster need is documented.
4. Membership type matches policy: flag domain,port members in a WWPN standard and the reverse.
5. Every zoned WWPN exists in your host inventory. Stale names from decommissioned hosts can be presented later by anyone.
6. No zone mixes environments or zones hosts to replicas they do not need (NIST AC-SS-R25 and AC-SS-R27).

A small script does most of this from a CSV of zone,member pairs and lists of known initiator and target WWPNs:

#!/usr/bin/env python3
"""zone_check.py zones.csv initiators.txt targets.txt

zones.csv: zone_name,member  (member is a WWPN like 21:00:... or domain,port as d:p)
initiators.txt / targets.txt: one WWPN per line
"""
import csv, re, sys
from collections import defaultdict

def norm(w):
    return w.strip().lower().replace("0x", "").replace(":", "")

zones = defaultdict(list)
with open(sys.argv[1]) as f:
    for zone, member in csv.reader(f):
        zones[zone.strip()].append(member.strip())

inits = {norm(l) for l in open(sys.argv[2]) if l.strip()}
targs = {norm(l) for l in open(sys.argv[3]) if l.strip()}
wwpn = re.compile(r"^[0-9a-f]{16}$")

for zone, members in sorted(zones.items()):
    w = [norm(m) for m in members if wwpn.match(norm(m))]
    ports = [m for m in members if not wwpn.match(norm(m))]
    hosts = [m for m in w if m in inits]
    unknown = [m for m in w if m not in inits and m not in targs]
    if len(hosts) > 1:
        print(f"{zone}: {len(hosts)} initiators in one zone")
    if ports and w:
        print(f"{zone}: mixes port members {ports} with WWPN members")
    if unknown:
        print(f"{zone}: unknown WWPNs (stale or unexpected) {unknown}")
    if not hosts:
        print(f"{zone}: no known initiator; check if still needed")

Before activating any change, save the configuration off the switch (NIST NC-SS-R5), change one fabric at a time, and confirm multipath health on the other fabric first.

Step 6: check LUN masking on the arrays

Export each array's host to volume mappings. Each host object should list only that host's current WWPNs, no volume should map to a larger host group than actually mounts it, snapshots and replicas should not map to production hosts without a documented reason, and hosts that no longer exist should be removed.

Step 7: enable authentication where supported

Do this in stages, in a maintenance window, one fabric at a time, following the documentation for your firmware version:

1. Fabric membership policy: list the switch WWNs allowed to join and, if supported, the IP addresses allowed to manage the fabric.
2. Switch to switch DH-CHAP on ISLs, with a long random secret per switch pair or a central RADIUS or TACACS server. Bring up one ISL at a time.
3. Host to switch authentication where HBA and switch firmware support it. Use an audit mode first if available (FC-SP-3 defines one), fix the ports that would fail, then enforce.
4. Frame encryption on paths that leave a controlled room first: replication links, inter building fibre, FCIP tunnels.
5. Disable unused switch ports persistently and restrict management ports (NIST NC-SS-R10 and NC-SS-R8).

Generate secrets with a proper random source, for example:

# 32 random bytes as hex; check the maximum length your switch and HBA accept
openssl rand -hex 32

Keep secrets in a secrets manager, one per device; a shared secret means one compromised host exposes all.

Step 8: log fabric changes and plan firmware updates

NIST SP 800-209 asks for current FC and IP network documentation (CM-SS-R9) and FC SAN security audits "at least annually, and in sensitive environments, at least quarterly, or after any major change" (CM-SS-R10).

On the switches, send syslog and audit logs to a central store over an encrypted transport and alert on zone set activation, zoning and policy changes, new E_Port links, authentication failures and default zone changes. Manage switches only over SSH and HTTPS (NIST EN-SS-R4) on a dedicated management network.

On the hosts, the kernel's FC transport reports rport arrivals and departures as device events, and recent kernels count fabric performance impact notifications (FPIN) per port:

# Watch remote ports appear and disappear in real time
udevadm monitor --kernel --subsystem-match=fc_remote_ports

# Link integrity, congestion and delivery events reported by the fabric
grep . /sys/class/fc_host/host*/statistics/fpin_* 2>/dev/null

The kernel's sysfs documentation describes these fpin_li, fpin_cn and fpin_dn counters as link integrity, congestion and delivery events reported through FPIN.

For firmware, keep HBA firmware and driver, switch operating system and array controller versions in one register, match them against vendor advisories, and update one fabric at a time on a fixed cadence.

Common mistakes

• Zoning by port only on switches in shared spaces. Port zoning trusts whoever plugs in. Combine port and WWPN membership or add authentication.
• Zoning by WWPN only, with no authentication. WWPNs can be set by software, so this stops mistakes, not impersonation.
• Default zone set to permit. A reset or new switch can expose every array to every host. Set deny and recheck after every switch replacement.
• Large multi initiator zones and stale WWPNs. Hosts see each other, RSCN storms spread, and decommissioned names wait to be reused.
• Both "fabrics" are really one. A stray ISL merges A and B. Check fabric_name on each host port.
• Shared management networks for switches. Management interfaces on the office LAN, with Telnet or HTTP enabled, put the fabric one password from any compromised laptop. Use a dedicated network, SSH and HTTPS, and an IP management allow list.
• No firmware update plan for HBAs and switches. They receive security fixes like any software. Track versions and patch on a schedule.
• Configuration backed up only on the switch, and FCIP links without IPsec. Keep exports off the SAN, and encrypt anything that crosses a WAN.

Where Safeguard fits

The fit is indirect. Safeguard does not manage Fibre Channel switches, configure zoning, or scan HBA, switch or array firmware. It helps with the software around the storage estate: provisioning scripts, inventory tools like the one in step 4, monitoring exporters and backup services built from open source dependencies and container images. Safeguard scans those repositories, images and SBOM files for known vulnerabilities, shows which projects carry a given component and version, ranks findings with reachability analysis and enforces policies and gates. Autonomous remediation can open fix pull requests and ships switched off.

A fabric is only as trustworthy as the software that manages it, and the provisioning tools, exporters and backup agents around a SAN pull open source dependencies just like any application. Patching those components quickly matters even though the fabric itself sits outside a software build, so the steps below apply to the storage team's own code and images rather than to switch or HBA firmware.

Fix it without waiting for upstream

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

1. Autonomous remediation: pull requests, not tickets

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

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

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

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

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

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

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

See how Safeguard would help

The first demo is a real Safeguard CLI session. It asks the assistant to fix a lodash CVE in a repository, reads the finding and advisory, asks before each command, edits package.json and runs the tests with approval, and pushes nothing. The same flow applies to an internal SAN inventory or provisioning tool whose dependencies carry a known vulnerability.

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

The second demo sets up the local runner on your own machine, approves it with a device code and then scans from the terminal. Storage teams often keep their tooling on hosts inside a restricted management network, and the runner lets those repositories and images be scanned close to where they live.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude may use. It suits teams who already ask Claude about infrastructure and want it to look up findings for the repositories and images behind their storage monitoring and backup services.

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

You can download Safeguard or read the CLI documentation to try the same flows on your own repositories.

FAQ

Is Fibre Channel encrypted?

Not by default. Base Fibre Channel sends data in the clear and relies on physical separation. FC-SP defines ESP_Header for per frame integrity and confidentiality, but both ends of each path must support and enable it.

Who maintains the Fibre Channel standards?

The INCITS Fibre Channel technical committee, called INCITS/T11 until January 2022. The Fibre Channel Industry Association publishes the speed roadmap but does not write the standards.

What is the difference between a WWN, a WWPN and a WWNN?

A WWN is any 64 bit Fibre Channel name. A WWPN names one port and a WWNN names a node, which may have several ports. Zoning and masking normally use the WWPN.

What is the difference between hard zoning and soft zoning?

In IETF usage, hard zoning is enforced by switches filtering frames and soft zoning relies on the name server and well behaved hosts. NIST SP 800-209 uses soft for WWN zoning and hard for port zoning. Ask separately how zones are enforced and how members are defined.

Is zoning a security control?

It is access control that prevents mistakes and limits blast radius. It does not prove identity, so pair it with FC-SP authentication, membership policies and physical security.

What is FC-SP-2 DH-CHAP?

The Diffie-Hellman Challenge Handshake Authentication Protocol from FC-SP. Switches, HBAs and arrays prove knowledge of a shared secret through a challenge and response strengthened by Diffie-Hellman, optionally deriving a session key for frame protection.

What is the fastest Fibre Channel speed?

Per the FCIA roadmap, single lane 128GFC reached the market in 2024 and the 256GFC specification was technically complete in 2025, with 512GFC and 1TFC targeted for 2029 and 2033.

How do I find the WWPN of a Linux server?

Read /sys/class/fc_host/host*/port_name. Each file holds one port's WWPN; node_name beside it holds the WWNN.

Quick check

Sources

• INCITS: Fibre Channel technical committee (formerly T11)
• Fibre Channel Industry Association: Fibre Channel Roadmap
• Fibre Channel Industry Association: FC-SP-3, a standard ready for the quantum computing world
• Fibre Channel Industry Association: Fibre Channel Security Prepares for Quantum Resistance, Q and A
• NIST SP 800-209: Security Guidelines for Storage Infrastructure
• RFC 5324: MIB for Fibre-Channel Security Protocols (FC-SP)
• RFC 4595: Use of IKEv2 in the Fibre Channel Security Association Management Protocol
• RFC 4936: Fibre Channel Zone Server MIB
• RFC 4438: Fibre Channel Name Server MIB
• RFC 4338: Transmission of IPv6, IPv4, and ARP Packets over Fibre Channel
• RFC 4626: MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol
• RFC 3821: Fibre Channel Over TCP/IP (FCIP)
• RFC 4172: iFCP, a Protocol for Internet Fibre Channel Storage Networking
• RFC 3643: Fibre Channel (FC) Frame Encapsulation
• RFC 7143: Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)
• Linux kernel documentation: SCSI FC Transport
• Linux kernel source: drivers/scsi/scsi_transport_fc.c
• Linux kernel ABI: sysfs-class-fc_host
• Linux kernel source: drivers/nvme/host/fc.c
• Linux kernel source: drivers/nvme/host/Kconfig
• Linux kernel source: drivers/scsi/qla2xxx/qla_edif.c
• nvme-cli documentation: fabrics options
• NVM Express: NVMe over Fabrics specification
• Wireshark source: packet-fc.h (well known addresses)
• Wireshark source: packet-fcels.h (ELS command codes)
• Wireshark display filter reference: Fibre Channel ELS
• fcoe-utils README
• lsblk(8) manual page

Last reviewed: 24 October 2026. Switch, HBA and array features differ by firmware version and licence; check your vendor documentation for what your fabric supports.