The unified management model for modern pluggables — one interface across QSFP-DD, OSFP and beyond.
What CMIS Actually Standardises
CMIS is not simply a tidier memory map, although it is that too. It is a behavioural specification: it says what a module must do between the moment power reaches it and the moment traffic flows, and it gives the host a defined way to ask for a configuration and be told whether it was granted.
The older SFF documents described where to find a number. CMIS describes a conversation. That is why it spans QSFP-DD, OSFP and QSFP112 without a per-form-factor dialect, and why a switch written against it can drive a module family it has never seen.
The Memory Map
Management is byte-addressed over a two-wire interface at address A0h. The lower 128 bytes are always visible and carry the identifier, the CMIS revision, the interrupt flags, the media type and the application descriptors. The upper 128 bytes are a window: the host writes a page number to byte 127 and the window shows that page.
Page 00h holds vendor identity, 01h capability advertising, 02h the alarm and warning thresholds behind DDM. Pages 10h and 11h are the working pair: 10h is where the host writes datapath control, 11h is where per-lane state and optical power come back. Byte 126 selects a bank, which is how a sixteen-lane module reaches lanes nine to sixteen.
State Machines and Application Advertising
A CMIS module runs a module state machine — management initialisation, low power, power up, ready — and a separate datapath state machine per lane group, cycling through deactivated, initialising and activated. Nothing about that is optional, which is precisely the point: a host knows what a module is doing rather than guessing from flags.
Application advertising is the part you feel every day. The module publishes a list of applications, each pairing a host electrical interface with a media interface and a lane count. The host stages a selection in Page 10h, sets an apply bit and waits for the datapath to reach activated. That handshake is what makes clean breakout possible — see the breakout configurator.
Revisions, and Why the Number Matters
The revision byte is worth reading before you buy. A module built to CMIS 5.x plugged into a switch whose driver was written against 4.0 usually works, because the spec is additive, but anything added since — coherent control, richer advertising, link training — simply will not appear. The reverse case, an older module in a newer host, is generally harmless.
Firmware update is handled through the Command Data Block mechanism rather than by raw register writes, which is how a module can be patched in service. If a supplier cannot tell you the CMIS revision their firmware implements, that is a more revealing answer than any compatibility list.
Where You Meet It
Whenever a 400G or 800G port is broken out, whenever a switch prints detailed module capability, and whenever a module is rejected for reasons that are not coding. Revision mismatch and coding mismatch produce similar symptoms and want different fixes — the unsupported transceiver guide separates them.
CMIS at a glance
| Custodian | QSFP-DD MSA through revision 5.1; OIF from 5.2 onward |
|---|---|
| Revision byte | lower page byte 1 — upper nibble major, lower nibble minor, so 0x50 is 5.0 |
| CMIS 3.0 | August 2018 — the first public release to see broad silicon support |
| CMIS 4.0 | May 2019 — VDM, CDB firmware update, tunable lasers, diagnostics pages 13h and 14h |
| CMIS 5.0 | May 2021 — a large consolidation: register map rework, CDB messaging, timing |
| CMIS 5.3 | September 2024 — co-packaged optics, ELSFP, link training, per-application power |
| CMIS 5.4 | May 2026 — up to 256 lanes, media lane switching, consolidated firmware load |
| Lanes addressed | 32, as four banks of eight, through 5.3; 5.4 raises the ceiling to 256 |
| Identifier byte 0 | 0x18 QSFP-DD, 0x19 OSFP, 0x1B DSFP, 0x1E a QSFP-family module run by CMIS |
Related Terms
DDM, MSA, EEPROM coding, QSFP-DD, DSP.