The quickest way to build an industrial asset inventory is to map ports to products. Port 502 is Modbus, 44818 is EtherNet/IP, 20000 is DNP3, 102 is Siemens. It works often enough to look right, and it is wrong in both directions.
It is wrong outward because plants move software. Historians, HMI web tiers and gateways get relocated to whatever port the site's change process allowed that year, and a product on a non-standard port disappears from a port-keyed inventory entirely.
It is wrong inward because a port says nothing about what is listening. A vendor tool, a test harness or an ordinary web server on 502 becomes a PLC in the report, and now an engineer is chasing a controller that does not exist.
Identify from what the service said
The rule we hold to is that a port list decides where a request is worth sending, and never what a thing is. Identification comes from evidence the service produced: a banner, a protocol handshake shape, a product string, a TLS certificate subject, a documented endpoint path.
Port 102 is the clearest case. Siemens S7comm and IEC 61850 MMS share it, because both ride ISO-on-TCP. A port-keyed inventory labels every substation protection relay a Siemens PLC. Telling them apart is a transport-selector discrimination during connection setup, which costs one exchange and invokes no service. Without it, an entire population of protection relays is either missed or mislabelled.
The evidence that costs nothing
Some of the strongest identification on an industrial network is volunteered.
ICONICS servers multicast a discovery announcement every three minutes carrying their version and hostname. BACnet devices answer a Who-Is with a device identifier and vendor. DNP3 outstations return manufacturer, product and software version in device attribute objects. A CIP identity reply names the vendor, product and device profile in a single datagram.
That evidence is worth more than a port and costs the device less. On a network where several ports are documented by their vendors as crashable by an unexpected message, preferring the read the device offers is both the safer and the more accurate choice.
Where the trap is: matching too loosely
Identification by content has its own failure mode, and it is worse than the port one because it looks like evidence.
A short token matched as a substring will fire inside ordinary words. We found a matcher looking for a product identifier that hit every page containing the word "export", and it reported at critical severity. A word that also occurs in normal text needs a second signal before it identifies anything.
The counterpart problem is a token so specific it never fires. In one of our own catalogues, 21 of 36 vendor probes could never have matched, because the expected-response field held a sentence describing what to look for rather than a substring that would appear in a body. They were written, cited, safety reviewed, and unable to produce a result.
Both are the same defect: the matcher was never tested against a real response. A signature that has not been run against the thing it identifies is a hypothesis with a version number.
The chicken and egg
One case is worth describing because it shapes how an inventory should be built.
A product with no unauthenticated banner cannot become a candidate from content, so the only route to identifying it is an open port. But a port alone is weak evidence, and for some products the corroborating marker costs a packet at a service that must never receive one.
The resolution is not cleverer matching. It is finding a read the device gives away for free, and building the identification on that. Where one exists, use it and stop. Where none exists, the honest inventory entry says the product could not be identified and states what was ruled out, which is a more useful line in a report than a confident guess.
What an inventory should carry
Three things, per asset: what it is, what said so, and how sure that makes us. The middle field is the one usually missing, and it is the one an engineer needs when they disagree with the first.
An inventory that cannot show its evidence is a list of opinions, and on a plant floor the person reading it usually knows the equipment better than the tool does.
Frequently asked questions
Why is a port-to-product mapping not a reliable way to build an OT asset inventory?
Because plants move software. Historians, HMI web tiers and gateways get relocated to whatever port a site's change process allowed that year, so a product on a non-standard port disappears from a port-keyed inventory. It is also wrong inward: a vendor tool or ordinary web server on port 502 becomes a PLC in the report.
Why do Siemens S7comm and IEC 61850 MMS both use port 102?
Both protocols ride ISO-on-TCP, which is why they share port 102. A port-keyed inventory would label every substation protection relay a Siemens PLC. Telling them apart is a transport-selector discrimination made during connection setup, costing one exchange and invoking no service, and without it a whole population of relays is missed or mislabelled.
What kind of evidence do industrial devices volunteer for identification?
Some of the strongest identification is free. ICONICS servers multicast a discovery announcement every three minutes carrying version and hostname, BACnet devices answer a Who-Is with a device identifier and vendor, DNP3 outstations return manufacturer, product and software version, and a CIP identity reply names vendor, product and device profile in one datagram.
What went wrong with a matcher that identified devices by a short text string?
A short token matched as a substring fires inside ordinary words. One matcher looking for a product identifier hit every page containing the word 'export' and reported it at critical severity. A word that also occurs in normal text needs a second signal before it can be trusted to identify anything.
Why could 21 of 36 vendor probes in one catalogue never match anything?
Because the expected-response field held a sentence describing what to look for rather than a substring that would actually appear in a device's response body. The probes were written, cited and safety reviewed, yet structurally unable to produce a result, showing that a signature never run against a real response is only a hypothesis with a version number.
What three things should an OT asset inventory record for every device?
What it is, what said so, and how sure that makes us. The middle field, the evidence, is the one usually missing, and it is what an engineer needs when they disagree with the identification. An inventory that cannot show its evidence is a list of opinions, not a record.