IoT segmentation · Buyer guide
IoT segmentation should define which services devices may access and how those boundaries will be tested. A drawing shows separate camera, printer and building-device VLANs, but nobody has agreed which systems may communicate. A useful segmentation order includes an approved access matrix and evidence that permitted services work while prohibited paths are blocked.
IoT segmentation: agree the access matrix
For each device class, name its owner, controller, management path and supporting services. Record source, destination, purpose and direction at the level the security designer needs. Cisco’s campus design guide provides architecture and security context; a site’s actual permissions require business ownership rather than copied example rules.
Define both positive and negative tests
For every important approved flow, identify a representative application check. For prohibited access, agree a safe authorised verification method. Avoid disruptive scanning or unapproved changes to operational devices. A camera displaying video does not prove that the camera network cannot reach an unrelated business system.
Include change and support ownership
Record who approves a new device or exception and who updates the matrix after a service change. Keep administrative access distinct from ordinary application traffic. Require a final configuration and evidence handover at an appropriate security level. The buyer should receive an understandable policy record without exposing credentials or sensitive rule details in public documents.
IoT segmentation: acceptance worksheet
Use the rows below to compare proposals. Enter the actual evidence reference, accountable owner and unresolved decision against each item. Keep provisional assumptions visible when asking bidders to revise their prices.
| Decision | Evidence to request | Purpose |
|---|---|---|
| Device class | Service and business owner | Accountable approver |
| Allowed flow | Source, destination and purpose | Positive test |
| Blocked flow | Policy boundary and safe method | Negative test |
| Change | New dependency or exception | Matrix revision |
Questions buyers ask
Do separate VLAN names prove isolation?
No. The routing and enforcement arrangement must implement the approved policy and be verified.
Should DNS or time services be recorded?
Include supporting dependencies that the actual devices require, with the designer validating the permitted paths.
Can live equipment be probed freely?
Use only authorised methods that account for operational impact and the relevant service owners.
Who approves an exception?
Name the business and security owners, with a reason and review condition.
What is the handover deliverable?
An approved flow matrix, controlled configuration record and traceable test evidence for the agreed cases.
Manufacturer research and scope
Cisco: campus LAN and wireless design guide, reviewed 31 October 2026. The buying worksheet is RIAM editorial analysis; it is not an OEM-approved design. Confirm current product, software, support and local requirements for the selected bill of materials.
Brief RIAM with the evidence
Share the existing inventory, the specific service or buying decision, available records and access constraints with RIAM’s security services team. Ask for a scoped assessment with deliverables, responsibilities, exclusions and acceptance evidence. Site work and production changes require the responsible owners’ approved plan.
Also read our guest isolation acceptance and CCTV PoE budget guide.
