How Optical Transceivers Are Made: Lasers, Photodiodes, DSPs, Firmware

An optical transceiver is made by growing laser and photodiode chips on compound semiconductor wafers (or building modulators in silicon photonics), aligning them to fiber with micron precision, and placing them on a small circuit board next to a laser driver, a transimpedance amplifier, often a DSP, and a microcontroller. The finished pluggable module is loaded with firmware and an identity memory map, calibrated, burned in and tested for eye quality and bit error rate. Your switch then talks to that microcontroller over a two-wire bus to read who made the module, how healthy it is and which firmware it runs.

This post goes one level deeper than our overview of AI data center optics and transceivers and our explainer on how fiber optic cables are made, and ends with a Linux walkthrough using ethtool.

Module makers do not publish yields, burn-in recipes or alignment tolerances, so where no primary source gives a number we say so, and the arithmetic examples are labelled illustrations.

Key takeaways

• A pluggable optic contains a transmitter (laser plus driver, or a continuous laser plus modulator), a receiver (photodiode plus transimpedance amplifier), very often a DSP that retimes and equalizes the signal, a management microcontroller, and nonvolatile memory holding the identity and diagnostics map.
• Short reach optics over multimode fiber typically use VCSELs. Longer reach single mode optics use edge emitting DFB lasers, electro-absorption modulated lasers (EMLs), or a continuous wave laser feeding silicon photonics modulators.
• Interoperability comes from multi-source agreements (MSAs) and SNIA SFF specifications, not from one vendor. QSFP-DD and OSFP define mechanics, electrical lanes and thermals; IEEE 802.3 defines the optical link; SFF-8472, SFF-8636 and the OIF's CMIS define the management memory map.
• SFF-8472 Rev 12.5a (16 January 2026) keeps identity at two-wire address A0h and diagnostics at A2h. Its checksum detects corruption; it does not prove who wrote the data.
• CMIS 5.4 (OIF, 21 May 2026) defines firmware banks A and B, run and commit commands, and an optional module authentication feature built on an IDevID certificate installed during manufacturing.
• Linux can read the memory map with ethtool -m and, where the driver supports it, flash CMIS module firmware with ethtool --flash-module-firmware, which downloads, runs and commits an image in that order.
• Linear pluggable optics remove the module DSP; co-packaged optics move the optical engine next to the switch chip and may move the lasers out to a separate pluggable source. Both shift where firmware lives and what you replace when something fails.

Wafer and fiber to tested module: the step table

This table is the map for the rest of the post. No module maker we found publishes stage yields, so the table names the check performed at each stage rather than inventing percentages.

Two rows matter most for anyone who runs a network. Step 11 is where the module's identity is written, the same data your switch later trusts. Steps 13 and 14 are why an unlabeled module with no test record is a gamble: the defects burn-in screens out are exactly the ones you would otherwise meet in production.

A dated timeline of the specifications

Dates below were checked on the publishing body's own page or document.

When we checked the IEEE SA page for P802.3dj it still listed the project as active, and the task force page had last been updated in July 2025. If you need a 1.6 Tb/s Ethernet citation, check the current status before quoting a standard number.

What is inside a pluggable optic?

Open an SFP, QSFP, QSFP-DD or OSFP module and you find the same functional blocks, scaled for lane count and speed.

The transmitter. At low speeds and short reach this is a laser that is switched on and off directly by a laser driver IC (direct modulation). At higher speeds and longer reach the laser runs continuously and a separate modulator imprints the data: an electro-absorption section on the same chip, or Mach-Zehnder or ring modulators in a silicon photonic chip. A monitor photodiode often samples the laser's light so the microcontroller can report transmit power. SFF-8472 says this plainly: the reported transmit power "is assumed to be based on measurement of laser monitor photodiode current."

The receiver. A photodiode turns light into a tiny current. A transimpedance amplifier (TIA) converts that current to a voltage the electronics can use. For 850 nm multimode links the photodiode is usually gallium arsenide; for 1310 nm and 1550 nm single mode links it is usually indium gallium arsenide, or germanium inside a silicon photonic chip. Long reach receivers can use avalanche photodiodes, which add internal gain.

The DSP or retimer. Modern 100 Gb/s per lane links use PAM4, which packs two bits into each symbol using four amplitude levels. The DSP recovers the clock, equalizes the electrical signal coming from the host, performs any lane rate conversion (a "gearbox"), and cleans up the signal coming back from the receiver. It is one of the largest power consumers in the module, which is why linear drive optics try to remove it.

The microcontroller and memory. A small microcontroller runs the module's firmware. It manages power up, laser bias loops, temperature compensation, alarms and the management interface. It exposes a memory map over a two-wire serial bus (I2C style) to the host. Identity fields, calibration constants and thresholds live in nonvolatile memory.

The housing and connector. The shell, latch, heatsink and edge connector are defined by the form factor MSA. The front holds an LC duplex receptacle for two fibers, or an MPO receptacle for parallel fibers, depending on the optical standard.

The form factors differ mainly in lane count, speed per lane and thermal headroom:

The identifier byte in the first location of the memory map tells the host which family it is talking to. SFF-8024 Rev 4.14 assigns, among others, 03h to SFP and later with SFF-8472, 0Dh to QSFP+ with SFF-8636 or SFF-8436, 11h to QSFP28 with SFF-8636, 18h to QSFP-DD, 19h to OSFP, 1Eh to QSFP+ or later with CMIS, and 20h to SFP+ and later with CMIS.

How are the lasers made, and why do VCSEL, DFB and EML differ?

All three are semiconductor lasers grown by epitaxy, but they are built differently and suit different links.

VCSELs for short reach

A vertical cavity surface emitting laser emits light straight up from the wafer surface. Its cavity is a thin active region sandwiched between two stacks of mirror layers grown in the same epitaxy run, usually on gallium arsenide for the 850 nm band. Because light leaves the top surface, every VCSEL on a wafer can be powered and measured before the wafer is cut, which is a large cost advantage: bad die are mapped out before anyone spends money packaging them. VCSELs couple easily into the wide core of multimode fiber, draw little current and are cheap, which is why they dominate short reach links inside a data hall. IEEE Std 802.3db-2022 is the recent amendment for 100, 200 and 400 Gb/s over short reach fiber.

Their limit is reach. Multimode fiber spreads pulses in time (modal dispersion), and the faster you signal, the shorter the usable distance.

DFB lasers for single mode links

A distributed feedback laser is an edge emitter: light travels along a ridge waveguide in the plane of the chip and exits from a cleaved facet. A grating etched along the cavity selects a single wavelength, which keeps the spectrum narrow enough for single mode fiber over kilometers. DFB lasers for the 1310 nm and 1550 nm bands are grown on indium phosphide. Because they emit from an edge, wafers are cleaved into bars, the facets are coated, and testing happens at the bar or chip level rather than across a whole wafer.

A DFB can be directly modulated, but at very high symbol rates the wavelength wobbles as the current changes (chirp), which limits speed and reach.

EMLs for higher speed and longer reach

An electro-absorption modulated laser integrates a DFB section running at constant current with an electro-absorption modulator section on the same indium phosphide chip. The modulator changes how much light it absorbs when a voltage is applied, so data is imprinted without disturbing the laser itself. The result is a cleaner, lower chirp signal suited to faster PAM4 lanes and longer single mode reaches, at a higher chip cost and with more complex fabrication.

Continuous wave lasers for silicon photonics

Silicon cannot efficiently emit light, so silicon photonic transmitters use a separate laser, often an indium phosphide DFB, running continuously. Its light is coupled into silicon waveguides and modulated there. In co-packaged designs that laser may sit in a separate front panel pluggable, which we return to below.

The wavelengths these lasers hit are not arbitrary. Coarse WDM optics place several lasers on the grid defined by ITU-T G.694.2, and IEEE 802.3 clauses and MSAs such as the 100G Lambda MSA fix the wavelengths, power budgets and reaches each module must meet. The 100G Lambda MSA, for example, defines 100 Gb/s PAM4 per optical channel for 2 km and 10 km reaches, using the same RS(544,514) forward error correction as the related IEEE specifications.

How photodiodes are made

Receiver photodiodes are simpler than lasers but follow the same flow: epitaxy of an absorbing layer (indium gallium arsenide for long wavelengths, gallium arsenide for 850 nm), a p-n or p-i-n junction, metal contacts and anti-reflection coating. Speed depends on keeping the junction small, which reduces capacitance, while responsivity depends on absorbing as much light as possible. Those two goals pull against each other, so high speed detectors are a careful compromise. Our p-n junction explainer covers the underlying device physics in plain terms.

Laser safety is a manufacturing requirement too

Every module is a laser product. In the United States, 21 CFR 1040.10 defines laser product classes; a Class I product is one that "does not permit access during the operation to levels of laser radiation in excess of the accessible emission limits" in the regulation's first table. Internationally, IEC 60825-1:2014 covers classification of laser products from 180 nm to 1 mm. Module makers design and test so that the product meets its declared class, which is why output power, not just data quality, is a final test item.

What is silicon photonics, and how are optical engines assembled and aligned?

Silicon photonics builds optical components (waveguides, splitters, modulators, photodetectors and couplers) on silicon on insulator wafers using tools and process steps borrowed from CMOS chip fabrication. Light is confined in thin silicon waveguides surrounded by oxide. Modulators change the refractive index of silicon by moving charge carriers, in Mach-Zehnder interferometers or tiny ring resonators. Germanium grown on silicon absorbs at 1310 nm and serves as the photodetector. The appeal is scale: many lanes of modulators and detectors on one chip, with wafer level testing and the manufacturing discipline of the semiconductor industry. Our semiconductor manufacturing explainer covers the shared fab steps.

Access to these processes is not limited to large companies. AIM Photonics, a US manufacturing innovation institute, describes its multi-project wafers as a way to "shorten design time" and lower the cost of entry for silicon photonics designs, with many designs sharing one wafer run.

An optical engine combines the photonic chip with electronic chips (drivers and TIAs, sometimes the DSP) in one package. Assembly has three hard problems:

1. Getting light in and out. Single mode fiber has a core of roughly ten microns, while silicon waveguides are far smaller. Grating couplers bend light up out of the chip surface; edge couplers taper the waveguide at the chip edge. Either way, a tiny misalignment costs a lot of optical power.
2. Active alignment. The usual approach is to power the laser or inject test light, then move the fiber or fiber array in several axes while measuring coupled power, and fix it at the peak with UV cured epoxy or laser welding. Passive alignment using etched grooves trades a little loss for speed and is used where the design allows.
3. Keeping it aligned. Epoxy shrinks as it cures and parts expand with temperature, so engines are checked again after curing and across temperature. This is one reason burn-in and temperature cycling remain part of final test.

The laser itself has to be attached too. Options include bonding an indium phosphide laser die onto the silicon chip, attaching a packaged laser with a lens, or feeding light from a laser outside the package entirely.

What do the multi-source agreements define, and why does a module from one maker work in another maker's switch?

No single standard defines a transceiver. Interoperability comes from several layers of agreements, each published by a different body:

The QSFP-DD MSA describes its goal as "ensuring mechanical, electrical, thermal and signal-integrity interoperability for module components produced by different manufacturers." The OSFP MSA describes its role as defining "the mechanical module, the card cage, the electrical interface and pinout." Neither says anything about which brand of switch a module must go in. A module built to these documents, and tested against the IEEE optical specifications, works in any host that also follows them.

So why do some switches reject some modules? That is a policy choice in the host software, covered in the vendor coding section below. It is not a limit imposed by the MSAs.

What firmware runs in a transceiver, and how do SFF-8472 and CMIS expose identity and diagnostics?

The firmware

Simple SFP modules may have no field update path at all. Modern 400G and 800G modules carry real firmware: the microcontroller image, DSP code and configuration data. CMIS 5.4 lists examples of updatable items, including "main controller firmware," "microcode in the module" and "code for internal devices such as converters or DSPs." The specification is deliberately neutral about what is inside an image: what can be updated "is module implementation dependent and outside the scope of the specification."

That firmware runs the laser bias loop, alarms, lane bring-up and DSP equalization. Bugs show up as flapping links, wrong diagnostics or modules that fail to initialize after a host upgrade.

SFF-8472: the SFP memory map

SFF-8472 Rev 12.5a describes the classic SFP layout. The original ID map sits at two-wire address A0h ("1010000x"), and the enhanced diagnostic map at A2h ("1010001x"). Each is 256 bytes, with optional pages in the upper half of A2h.

Identity fields at A0h include:

The check code is worth understanding precisely. SFF-8472 defines CC_BASE as "the low order 8 bits of the sum of the contents of all the bytes from byte 0 to byte 62." That catches corrupted memory. It provides no protection against someone who rewrites the fields and recomputes the sum, because there is no key involved.

The diagnostics at A2h report five core values. SFF-8472 fixes their encoding:

Two worked examples show how a host turns raw bytes into readings. Both are illustrations using the published encoding, not readings from a specific product.

Worked example 1: transmit power. Suppose the two transmit power bytes read 13h and 88h. As a 16-bit value that is 0x1388, or 5,000. At 0.1 microwatts per step, that is 500 microwatts, or 0.5 mW. In dBm, 10 times log10(0.5) is about minus 3.01 dBm. If the receive power at the far end reads 0x07D0 (2,000, so 200 microwatts, about minus 6.99 dBm), the link is losing roughly 4 dB between the two modules, which is the number to compare against the optical budget in the relevant IEEE clause. Remember the accuracy floor: each reading may be off by up to 3 dB, so a 4 dB difference between two modules is a prompt to clean and inspect connectors, not proof of a bad fiber.

Worked example 2: temperature and bias. Temperature bytes 1Ah and 80h give 0x1A80, or 6,784. Divided by 256, that is 26.5 degrees C. Bias bytes 17h and 70h give 0x1770, or 6,000 steps of 2 microamps, which is 12.0 mA. The useful signal is the trend: lasers usually need more bias current to keep the same output as they age, so a bias reading creeping up month over month at a steady temperature is an early warning worth graphing.

SFF-8472 also says vendor specific pages "may be password-protected," and that the password location "will be defined by the vendor." Keep that line in mind for the vendor coding discussion.

SFF-8636: four lane modules

QSFP+ and QSFP28 modules follow SFF-8636, now at Rev 2.12 (29 April 2026), which "defines a common management interface for 4-lane pluggable transceiver modules and cable assemblies." It uses a single two-wire address with a lower page and selectable upper pages, and reports per lane bias, transmit and receive power instead of single values.

CMIS: the management interface for 400G and beyond

The Common Management Interface Specification was started under the QSFP-DD MSA. The MSA site now notes that "CMIS future work and archives of current and past CMIS specification are now under the OIF," with CMIS 5.1 and earlier archived there. Revision 5.4, dated 21 May 2026, is the version we reviewed.

CMIS defines a paged memory map, a module state machine (low power, high power, data path states per lane), per lane monitors, and a Command Data Block (CDB) messaging channel for operations too large for simple register writes, including firmware management, performance monitoring statistics and security features. CMIS is also used for some SFP class modules: SFF-8024 has an identifier for "SFP+ and later with Common Management Interface Specification," and SFF-8472 notes that SFP modules capable of 100 Gb/s or more are expected to use CMIS.

How CMIS firmware update works

The CMIS firmware model is worth knowing in detail because it decides how safely a module can be upgraded:

• Two banks and a fixed load. Modules may have up to two host updatable firmware banks, A and B, and may also have "a hidden and not field-updatable fixed bank containing a fixed factory-loaded firmware" that at least lets the host repair the other banks.
• Three statuses per bank. Administrative status says which bank is committed to run after a reset. Operational status says which bank is running now. Validity says whether the bank holds a complete, undamaged, runnable image.
• Commands. CDB command 0100h gets firmware information; 0101h starts a download; 0103h and 0104h write image data; 0107h completes it; 0108h copies between banks; 0109h runs a load; 010Ah commits it. A host can run new firmware first and commit only after it has proven itself, so a bad image does not survive the next reset.
• Opaque images. The download file has "a vendor specific and host transparent header section" followed by the firmware itself. The host does not interpret the contents.
• One version for the whole bundle. CMIS strongly recommends that the reported revision numbers refer to the complete "firmware load," not one component, and that revision plus build number and extra string identify exactly one configuration. Since CMIS 5.4, all four version components are available in registers on Page 0Dh.

That last point matters for inventory. If revision numbers identify the whole bundle, you can track module firmware the way you track package versions. If a vendor reuses a version number across different builds, your inventory will lie to you.

CMIS also contains an editor's note that "supporting the capability to upload firmware may also raise security concerns," referring to optional firmware readback. Reading firmware out of a module makes it easier to inspect, and easier to copy or modify.

Module authentication in CMIS

CMIS 5.4 describes one optional CDB security feature, Module Device Authentication. In the specification's words, it is "based on a cryptographically protected Initial Device Identity (IDevID) certificate which is securely installed during module manufacturing." The certificate contains the module's serial number, product ID and public key, signed by a certificate authority, and the module proves possession of the private key in a challenge-response exchange. CMIS notes that trustworthy modules "are built upon hardware-based roots of trust," and that without them "there can be no assurance of integrity or authenticity." The CDB command group 0400h to 0406h covers these commands, including 0400h to fetch the certificate.

This is the first standardized way for a host to distinguish a module that was really built and keyed by its maker from one whose EEPROM strings were edited. Because it is optional, check the module's advertised support rather than assuming it.

What is vendor coding and optic locking, and what are the integrity concerns?

Some switch and router operating systems read the identity fields, and sometimes vendor specific data, from every inserted module and compare them against a list of approved part numbers. If the module is not on the list, the host may log a warning, refuse to enable the port, or enable it with a flag that support contracts can see. This is commonly called optic locking or vendor locking.

The market response is "coded" or "compatible" optics: modules built to the same MSAs and IEEE specifications whose identity fields are programmed to match the part numbers a given host expects. Some coding is done at the factory, and some is done in the field by rewriting the EEPROM with a programming tool.

We are not taking a side on whether locking is good policy. The integrity concerns are the part that matters for security and operations:

1. Identity strings are not proof of origin. SFF-8472 identity fields are protected only by an additive check code. Anyone who can write the memory can change the vendor name, part number and serial, and recompute CC_BASE. An inventory built purely from ethtool -m strings tells you what the module claims, not who made it.
2. Calibration and thresholds live in the same memory. Careless reprogramming can overwrite calibration constants or alarm thresholds, so diagnostics read wrong while the link still comes up. You find out when an alarm that should have fired never does.
3. Firmware provenance. For CMIS modules with updatable firmware, a module may have been reflashed outside the maker's process. Without module authentication you cannot distinguish that from a factory image by reading version registers alone.
4. Password defaults. CMIS defines 32-bit passwords for custom protected features, with host passwords in the range 0000 0000h to 7FFF FFFFh and module passwords from 8000 0000h to FFFF FFFFh. The specification states that "the factory default of a Host Password is 0000 1011h." A well known default protects nothing unless it is changed, and CMIS also prohibits password protection of CMIS standardized features unless explicitly specified.
5. Counterfeit and grey market parts. Modules relabelled from cheaper, slower or out of spec parts can pass a link-up test but fail optical budgets, temperature range or reliability screening. The burn-in and test steps in the table above are what you lose.

The practical response is procurement discipline plus verification: buy from sources that provide test data, keep serial numbers and firmware versions in an inventory, compare diagnostics against expected ranges at install time, and where the module and host support it, use CMIS module authentication.

What are linear drive and co-packaged optics, and how do they change firmware and failure?

Linear pluggable optics (LPO)

The LPO MSA describes its approach as "removing the digital signal processing (DSP) function from the pluggable optical module," relying on the switch chip's own SerDes to do the equalization. It lists lower power, lower latency and lower module cost as benefits, and says it will specify interoperability "starting at 100 Gb/s per lane," extending to 200 Gb/s per lane. The earlier Open Eye MSA pursued a related idea, "minimizing the need for signal processing in optical modules," starting at 53 Gb/s per lane PAM4.

What changes:

• Less firmware in the module. Without a DSP, the module has no DSP microcode to update. The microcontroller still manages the laser, monitors and the management interface.
• More dependence on the host. Link quality now depends on the host SerDes and its tuning for the specific module and channel. A host software update can change link behaviour, and interoperability has to be validated as a host plus module pair.
• Different failure diagnosis. With no retimer in the middle, errors cannot be cleanly attributed to "the host side" or "the optical side" of the module. Diagnostics rely more on host statistics.

Co-packaged optics (CPO)

Co-packaged optics put optical engines on the same package or substrate as the switch ASIC, so electrical signals travel millimeters instead of across a board to the front panel. The OIF's Co-Packaging Framework Document (3 February 2022) addresses "co-packaging of optical and electrical communication interfaces with one or more ASICs," and the OIF's 3.2 Tb/s co-packaged module agreement (29 March 2023) specifies electro-optical-mechanical details of one module design.

A key design choice is where the lasers live. The OIF framework notes that external laser sources "can improve the reliability of a CPO switch because lasers that have failed may be swapped at the faceplate without removing the switch from operation," and that separating lasers from the ASIC improves the thermal environment for both, at the cost of "higher insertion loss" that the external laser must make up with more power. The framework also notes that VCSEL based engines with multimode fiber could be the lowest cost and lowest power option for short reach CPO. The OIF's ELSFP agreement (4 September 2024) defines CMIS management for those external laser pluggables, so even a CPO switch keeps a CMIS-managed pluggable at the front panel.

For operations teams the headline is simple. With pluggables, a dead laser is a two minute swap. With CPO, the field replaceable unit shrinks to the external laser source, and everything else becomes part of the switch platform, its firmware and its update process.

Step by step: read a transceiver's identity, firmware and diagnostics on Linux

These steps use ethtool, which talks to the kernel's ethtool netlink interface. Whether a NIC driver supports module EEPROM reads, CMIS paging and firmware flashing varies, so expect some commands to return "Operation not supported" on some hardware. Steps 1 to 6 only read data.

1. Find the interfaces and their drivers.

ip -br link
for i in $(ls /sys/class/net | grep -v '^lo$'); do
  printf '%s ' "$i"; ethtool -i "$i" 2>/dev/null | grep -E '^driver:' || echo
done

2. Read and decode the module's memory map.

sudo ethtool -m eth0

On an SFP you will see the identifier, connector, vendor name, OUI, part number, revision, serial, date code, and, if diagnostics are implemented, temperature, voltage, bias, and transmit and receive power with alarm and warning thresholds. On a CMIS module you will also see module state, per lane values and, depending on the ethtool version, firmware revision fields. The ethtool manual describes -m as retrieving "and if possible" decoding "the EEPROM from plugin modules, e.g SFP+, QSFP."

3. Pull out just the identity fields for an inventory.

for i in $(ls /sys/class/net | grep -v '^lo$'); do
  out=$(sudo ethtool -m "$i" 2>/dev/null) || continue
  vn=$(echo "$out" | awk -F': ' '/Vendor name/{print $2; exit}')
  pn=$(echo "$out" | awk -F': ' '/Vendor PN/{print $2; exit}')
  sn=$(echo "$out" | awk -F': ' '/Vendor SN/{print $2; exit}')
  rev=$(echo "$out" | awk -F': ' '/Vendor rev/{print $2; exit}')
  echo "$(hostname),$i,$vn,$pn,$rev,$sn"
done

Store the output with a timestamp. A serial number that moves between hosts, or two ports reporting the same serial, is a lead worth chasing.

4. Dump raw pages in hex when decoding is incomplete.

sudo ethtool -m eth0 hex on
# A single page or part of one (CMIS page 0Dh, upper half):
sudo ethtool -m eth0 page 0x0d offset 128 length 128

The kernel interface reads at most half a page per request. Its documentation says only "dumps of 128 (or less) bytes are allowed, without crossing half page boundary," and for pages other than 0 "only high 128 bytes are accessible." When you pass page, bank or i2c parameters, the manual notes that only a single page or part of one is dumped.

5. Check the module power mode and state.

sudo ethtool --show-module eth0

This shows the power mode policy and operational power mode. With the policy set to auto, the manual says the module moves to high power when "the first port using it is put administratively up" and back to low power when the last port goes down.

6. Check error correction and link health.

sudo ethtool --show-fec eth0
sudo ethtool -S eth0 | grep -iE 'fec|crc|symbol|err' | head -40

Rising corrected FEC counts with steady traffic usually mean the optical or electrical margin is shrinking. Compare them with the receive power and bias trends from step 2.

7. Verify the target before any firmware change.

Warning: the next step writes firmware to a transceiver. A wrong image, a wrong interface or a power interruption can leave a module unusable or a link down, and the update can take several minutes. Do it only in a maintenance window, on a port you can take down, with an image supplied by the module's maker for that exact part number.

First confirm you are pointing at the module you think you are, and record its current firmware:

IF=eth0
sudo ethtool -m "$IF" | grep -E 'Identifier|Vendor name|Vendor PN|Vendor SN|Vendor rev|[Ff]irmware'
# Stop here unless the vendor PN and serial match the module named in your change ticket.
ip link show "$IF"

8. Flash CMIS module firmware (destructive, read the warning above).

IF=eth0
# Re-check the target immediately before writing.
sudo ethtool -m "$IF" | grep -E 'Vendor PN|Vendor SN'
sudo ip link set "$IF" down
sudo ethtool --flash-module-firmware "$IF" file vendor-module-fw.bin
sudo ethtool --monitor   # in another terminal, to watch progress notifications

The kernel documentation describes what happens: the image is downloaded to the module and validated, then run, then committed "so that it is run upon reset," in that order. The request "merely schedules the update process and returns immediately," and the kernel emits progress notifications with started, in progress, completed or error status. An optional pass argument supplies a module password if the maker requires one. The file name is resolved by the kernel's firmware loader, so on most distributions the image goes under the firmware directory (commonly /lib/firmware); check your distribution and driver documentation.

9. Confirm the result.

sudo ethtool -m "$IF" | grep -iE 'firmware|Vendor SN'
sudo ip link set "$IF" up
sudo ethtool --show-fec "$IF"

Record the new firmware version in your inventory against the serial number.

Common mistakes

• Treating identity strings as authentication. The vendor name and part number are writable fields with a simple checksum. Use them for inventory, not as proof of origin.
• Comparing power readings across modules to a decimal place. Each SFF-8472 reading may be 3 dB off. Use trends on one module and a power meter for acceptance tests.
• Ignoring bias current trends. Output power can look stable while the laser needs more and more current to hold it. Graph bias over months.
• Flashing firmware without checking the part number. Firmware images are vendor and part specific, and CMIS treats the image contents as opaque. The host will not stop you from sending the wrong file.
• Committing before testing. CMIS separates run from commit for a reason. Where your tooling allows, run the new load, test traffic and FEC counters, then commit.
• Mixing LPO modules and hosts without validation. Linear modules depend on host SerDes tuning. Validate each host and module combination before rollout.
• Forgetting that module firmware is part of your inventory. Teams track switch operating system versions carefully and module firmware not at all. A module bug fix you never deployed is still a bug.
• Leaving a well known default password in place. If you use password protected custom features, change the factory host password.
• Buying optics with no test data. Without burn-in and final test records you cannot tell a screened module from a relabelled one.

FAQ

What is inside an SFP or QSFP transceiver?

A laser and laser driver (or a continuous laser and modulator) for transmit, a photodiode and transimpedance amplifier for receive, often a DSP or retimer, a management microcontroller, and nonvolatile memory with the identity and diagnostics map, all in a shell defined by the form factor MSA.

What is the difference between VCSEL, DFB and EML lasers?

A VCSEL emits from the wafer surface, is cheap and suits short multimode links. A DFB emits from a cleaved edge with a grating that holds one wavelength, suiting single mode links. An EML adds an electro-absorption modulator to a DFB on the same chip for cleaner high speed signals over longer reach.

How do I read SFP diagnostics on Linux?

Run sudo ethtool -m <interface>. If the module implements digital diagnostics and the driver supports module EEPROM reads, ethtool decodes temperature, supply voltage, laser bias, and transmit and receive power, with alarm and warning thresholds.

What is CMIS in optical transceivers?

The Common Management Interface Specification, now maintained by the OIF, is the memory map and command interface used by QSFP-DD, OSFP and other modern modules. It covers identity, module and lane states, diagnostics, and a Command Data Block channel for firmware updates and security features.

Can you update transceiver firmware?

Many CMIS modules support field updates through CDB commands, with up to two firmware banks and separate run and commit steps. On Linux, ethtool --flash-module-firmware drives this where the NIC driver supports it. Simple SFP modules often have no update path.

Why do some switches reject third party optics?

Some host operating systems compare a module's identity fields against an approved list and refuse or flag unlisted modules. The MSAs themselves do not require this; it is a host software policy.

Are coded or compatible optics safe to use?

Many are built to the same MSAs and IEEE specifications. The risks are in provenance and process: reprogrammed identity data, possibly altered calibration or thresholds, and unknown screening. Buy with test data, verify diagnostics at install time and keep an inventory of serials and firmware.

What is the difference between LPO and CPO?

Linear pluggable optics keep the pluggable module but remove its DSP, relying on the host's SerDes. Co-packaged optics move the optical engine onto the switch package, often with lasers in separate front panel pluggables, and change what can be replaced in the field.

Is silicon photonics the same as a silicon laser?

No. Silicon photonics builds waveguides, modulators and germanium detectors on silicon, but the light source is usually a separate indium phosphide laser attached to the chip or fed in from outside.

Where Safeguard fits, honestly

Safeguard does not make, test or analyse transceivers. It does not scan module firmware, verify module certificates, generate a hardware bill of materials or manage network devices, and its models are single-purpose security models for software. The fit is narrower and indirect: the software that manages optics is ordinary software. Inventory collectors that run ethtool, network automation in Python or Go, telemetry exporters that graph bias and FEC counters, and the container images that package all of them carry open source dependencies with their own known vulnerabilities. Safeguard scans those repositories, container images and SBOM files, shows which projects carry a given component and version, and can open fix pull requests when a fixed version exists, with autonomous remediation switched off by default.

Every rebuilt network automation image pulls its libraries again, and switch operating systems, NIC drivers and management agents ship open source components of their own. The hardware stays with module makers and host vendors; the software you build around it is where supply chain hygiene still applies.

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 asked to fix a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, runs npm install and npm test with approval and pushes nothing. The same flow fits an optics inventory dashboard or network telemetry service your team maintains.

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

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. That suits network teams who build automation and collector images on their own hardware and want scans to run there.

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 can use. A network engineer can then ask about the components in the repositories that hold their fleet tooling without granting broader access than they intend.

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

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• SNIA, SFF-8472 Rev 12.5a, Management Interface for SFP+ (16 January 2026)
• SNIA, SFF-8636 Rev 2.12, Management Interface for 4-lane Modules and Cables
• SNIA, SFF-8024 Rev 4.14, SFF Module Management Reference Code Tables
• SNIA, SFF-8419 Rev 2.0a, SFP+ Power and Low Speed Interface
• OIF, Common Management Interface Specification Revision 5.4 (21 May 2026)
• OIF, Implementation Agreements index
• OIF, Co-Packaging Framework Document (3 February 2022)
• OIF, 3.2 Tb/s Co-Packaged Module Implementation Agreement (29 March 2023)
• OIF, External Laser Small Form Factor Pluggable CMIS Implementation Agreement (4 September 2024)
• QSFP-DD MSA
• OSFP MSA
• LPO MSA
• Open Eye MSA
• 100G Lambda MSA
• IEEE P802.3cu Task Force (802.3cu-2021)
• IEEE P802.3db Task Force (802.3db-2022)
• IEEE P802.3df Task Force (802.3df-2024)
• IEEE P802.3dj Task Force
• IEEE SA, P802.3dj project page
• Linux kernel documentation, ethtool netlink interface
• Linux kernel documentation, phylink and SFP
• ethtool(8) manual page
• eCFR, 21 CFR 1040.10 Laser products
• IEC 60825-1:2014 Safety of laser products, Part 1
• ITU-T G.694.2, CWDM wavelength grid
• Telcordia GR-468, Reliability Assurance Requirements for Optoelectronic Devices Used in Telecommunications Equipment
• AIM Photonics

Last reviewed: 23 October 2026.