Cybersecurity

IoT Security RFP Template (Free): Requirements and Scoring

Paste-ready IoT security requirements (device discovery and profiling, vulnerability context, segmentation via NAC and firewalls, OT and IoMT), vendor questions and a scoring rubric.

14 pages Microsoft Word ★ 5 of 5 4364 downloads Updated October 9, 2026
Download Template
IoT Security Solutions RFP Template

Preview the first pages

See the structure before you download. The Word file has every section listed below, ready to fill in.

Open preview Give feedback

What's inside

The sections in the document, in order.

  1. How to run an IoT Security RFP
  2. IoT Security RFP requirements
  3. Questions to ask IoT Security vendors
  4. Scoring rubric
  5. Frequently asked questions
  6. Related RFP templates

Use this IoT security RFP template when you need to find, classify and protect the connected devices that can't run an endpoint agent: cameras, printers, building controls, badge readers, medical equipment and industrial systems.

The requirements reflect how the category works in 2026: agentless discovery and profiling, risk and vulnerability context for each device, and segmentation enforced through the NAC, firewalls and switches you already run, with OT and medical device coverage as options.

It's written for the security, network and device-owner teams running the evaluation, and it covers when to issue an RFI first, the requirements to send, the questions that separate vendors, and how to score the answers.

What’s inside this template

  • A step-by-step plan for running the evaluation, with an example schedule, a proof-of-value plan and advice on when an IoT security RFI should come first
  • Requirements for passive and active discovery, device profiling, vulnerability context, risk scoring, threat detection and segmentation, each marked Must-have or Nice-to-have
  • Optional requirements for OT networks and medical devices (IoMT) that you can raise to Must-have
  • Questions that test classification depth, the safety of active discovery, enforcement through your NAC and firewalls, and what data leaves your network
  • A weighted scoring rubric with 1-to-5 definitions
  • An editable Word RFP with response codes, a pricing table and a timeline

Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.

How to run an IoT Security RFP

An IoT security evaluation crosses the security, network and facilities teams, and often OT and clinical engineering too, and you usually start without an accurate count of the devices in scope. The example schedule in this template runs about 12 weeks from kickoff to contract award; allow more if the proof of value covers several sites, or OT and clinical networks that need change approval first.

  1. Agree on drivers and scope (weeks 1-2). Write down why you're buying (an audit finding, a segmentation project, an incident, a new building or plant) and which sites and networks are in the first phase. Estimate device numbers from DHCP leases, NAC logs and switch MAC address tables, and list the device groups you know about: cameras, printers, building systems, badge readers, medical devices and industrial controllers. Record the numbers vendors will price against: sites, network segments and estimated devices.
  2. Assemble the buying team. Include security operations, the network team (which owns switches, traffic mirroring, NAC and firewalls), IT asset management, and the owners of each device population, such as facilities, OT engineering and clinical engineering. Add procurement, legal and privacy. OT and clinical engineering should approve anything that touches their networks, including the proof of value.
  3. Map where you can collect traffic, and decide whether you need an RFI (weeks 2-4). List where traffic can be mirrored (SPAN ports or TAPs), which switches and wireless controllers could supply device data instead, and which sites have no spare capacity. Decide whether you're buying a dedicated IoT security platform or extending the device profiling in your NAC or firewall. If that's still open, or your long list has more than five vendors, issue a short RFI about coverage, deployment model and pricing metric, and use the answers to build a shortlist.
  4. Tailor and issue the RFP (weeks 4-7). Delete requirements that don't apply, raise the OT or medical device requirements to Must-have if those networks are in scope, and add your environment details to Section 1. Give vendors three weeks to respond, with a written question-and-answer window in the first week.
  5. Score the responses (weeks 7-8). Have each evaluator score independently against the rubric before comparing notes, and set aside any vendor that misses a Must-have. Check every 'yes' for whether it needs a separate module, a partner product or a feature still in preview.
  6. Run a proof of value with two or three vendors (weeks 8-11). Give each vendor the same mirrored traffic at one representative site, in passive-only mode first. Before it starts, verify a sample of devices by hand, then compare each product's inventory against it: how many devices it finds, how deeply it classifies them and how many it leaves unknown. Test one segmentation policy in simulation mode and then through your NAC or firewall, check what data leaves the site, and call references.
  7. Negotiate and award (weeks 11-12). Use the pricing table to compare like for like. Agree how devices are counted, who owns and replaces sensor hardware, and what happens when the device count grows, and settle renewal caps and exit terms before you sign.

IoT Security RFP requirements

Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.

Functional

ID Requirement Priority
F1 Continuous discovery of every IP-connected device on the networks in scope, including IoT, OT, medical, building-system and unmanaged IT devices on wired, wireless and remote-site networks, with passive traffic analysis as the default method. Must-have
F2 Optional active discovery that is safe for fragile devices: targeted queries in each device's own protocols, configurable by network segment and device type, and switchable off entirely for networks we specify. State which device types are excluded from active queries by default. Must-have
F3 Discovery from existing sources without extra sensors, including switches, wireless controllers, DHCP, DNS, NAC, firewalls, EDR, MDM and our CMDB, merged into one record per device without duplicates. Must-have
F4 A profile for each device showing manufacturer, model, device type and function, operating system and firmware version, serial number where visible, MAC and IP addresses, switch port or access point, VLAN, site, and first-seen and last-seen times. State how classification confidence is shown. Must-have
F5 Tools for us to correct a classification, add custom attributes such as owner, department and business criticality, and define our own device types, with our changes kept when the device is seen again. Must-have
F6 A communication map for each device and device group showing internal and external destinations (including manufacturer cloud services), protocols and ports, with a learned baseline of normal behavior. Must-have
F7 Vulnerability context without scanning: matching of each device's model and firmware to published CVEs and manufacturer advisories, with vulnerabilities in the CISA Known Exploited Vulnerabilities (KEV) catalog flagged. State how matching works when the firmware version can't be determined. Must-have
F8 Detection of insecure configurations, such as default or weak credentials, clear-text management protocols (Telnet, FTP, HTTP), outdated TLS versions, open management ports and unsupported operating systems. State which checks are passive and which need active testing. Must-have
F9 A risk score for each device that combines vulnerabilities, exploitability, insecure configurations, exposure (for example, reachable from the internet or sitting on a flat network), observed behavior and business criticality, with the factors behind each score shown. Must-have
F10 Threat detection based on device behavior: deviations from baseline, connections to destinations on built-in or customer-supplied threat-intelligence lists, scanning, lateral movement and unexpected protocols. Each alert names the device, the behavior and the supporting evidence. Must-have
F11 Segmentation policy recommendations derived from observed communications and grouped by device type or function, with a simulation mode that shows which traffic a policy would block before it is enforced. Must-have
F12 Enforcement through our existing controls: quarantine or VLAN assignment through our NAC, and device groups or tags that our firewall policies can reference, updated automatically as devices are classified. State which actions the product takes directly, which depend on a third-party product, and whether actions can require manual approval. Must-have
F13 Remediation tracking: assignment of findings to device owners, ticket creation, status through to closure, and recorded risk acceptances and compensating controls (such as segmentation for devices that can't be patched) with review dates. Must-have
F14 Alerts when a new device appears, when a known device changes firmware, behavior or location, or when a device type we haven't approved connects, configurable by site and network segment. Must-have
F15 OT coverage: passive decoding of industrial protocols such as Modbus, DNP3, EtherNet/IP, PROFINET, OPC UA, IEC 60870-5-104 and IEC 61850, mapping of assets to Purdue model levels, and detection of controller program downloads, mode changes and firmware changes. Make this Must-have if OT networks are in scope. Nice-to-have
F16 Medical device (IoMT) coverage: identification of clinical devices from their traffic, including HL7 and DICOM, links from each device to the manufacturer's security disclosure (MDS2 form) and recalls, and remediation workflows shared with clinical engineering. Make this Must-have if you are a healthcare provider. Nice-to-have

Technical and architecture

ID Requirement Priority
T1 Sensors available as physical appliances and as virtual machines that receive mirrored traffic from SPAN ports, TAPs or remote SPAN, with published throughput, interface and storage specifications. State whether sensors can also run on our network devices. Must-have
T2 A passive-only mode in which sensors send nothing onto the monitored networks, for use on OT and clinical networks. Must-have
T3 Management offered as a SaaS service, a self-hosted deployment or both. State which features differ between the two. Must-have
T4 Fully air-gapped operation, with device classification, vulnerability and threat-detection content updated offline. Make this Must-have for isolated OT networks. Nice-to-have
T5 Classification of devices whose traffic is encrypted, using metadata and without decrypting the traffic. State which attributes and checks are unavailable for encrypted traffic. Must-have
T6 Coverage of small and remote sites where a sensor isn't practical, through integration data or lightweight collectors. State the minimum footprint per site and the bandwidth used between sensors and the management service. Must-have
T7 Support for [number] devices across [number] sites, with published limits per sensor and per management instance, and role-based scoping of data by site, region or business unit. Must-have
T8 High availability for the management service, and documented behavior when a sensor loses contact with it, including how long the sensor buffers data locally. Must-have
T9 Visibility of devices on non-IP or non-Ethernet networks, such as serial or fieldbus devices behind gateways, Bluetooth Low Energy or Zigbee. State which are covered and how. Nice-to-have

Integration

ID Requirement Priority
I1 Two-way integration with our NAC: device classification and risk shared with the NAC for access policy, and NAC actions (quarantine, VLAN change, re-authentication) triggered from the platform. List the pre-built NAC integrations. Must-have
I2 Integration with our firewalls so that device groups, tags or address objects stay current as devices are classified, for use in segmentation rules. List the supported firewalls and how updates are delivered. Must-have
I3 Collection of device and port data from our switches and wireless controllers via SNMP, APIs or controller integrations, with optional enforcement through switch ACL or VLAN changes. Must-have
I4 Streaming of alerts, inventory changes and administrator audit logs to our SIEM via syslog (CEF) and a REST API, in a documented schema. State whether OCSF is supported. Must-have
I5 Two-way synchronization with our ITSM platform and CMDB: creating and updating configuration items with device attributes, and opening tickets for findings. Must-have
I6 Administrator sign-in through our identity provider via SAML 2.0 or OIDC, with roles mapped from identity-provider groups. Must-have
I7 Import of results from our vulnerability scanners, EDR and MDM to enrich device records, and export of a list of fragile devices for our scanners to exclude from active scans. Nice-to-have
I8 A documented REST API and webhooks for inventory, risk, alerts and enforcement actions, so our SOAR playbooks can look up devices and trigger containment. Nice-to-have

Security and compliance

ID Requirement Priority
S1 A current SOC 2 Type II report and ISO/IEC 27001 certification covering the proposed service, available under NDA. Must-have
S2 A clear statement of what data leaves our network (metadata only, or packet contents), where it is stored and for how long. We must be able to keep packet captures on our premises, or turn them off for networks we specify. Must-have
S3 Choice of the region where our data is stored and processed, isolation of our tenant's data, and encryption in transit (including between sensors and the management service) and at rest. Must-have
S4 Administrator access through SSO with MFA, role-based permissions, approval steps for enforcement actions, and an audit log of every configuration change and enforcement action. Must-have
S5 Hardened sensors with secure boot and signed updates, a published vulnerability disclosure process, committed timelines for fixing security flaws in sensors and software, and a software bill of materials (SBOM) for the components we host, on request. Must-have
S6 Reports that map device inventory, risk and segmentation status to the frameworks we use [for example, NIST CSF 2.0, ISA/IEC 62443, the HIPAA Security Rule or PCI DSS]. State which frameworks have pre-built reports. Must-have
S7 A data processing agreement, a current list of sub-processors, and a contractual commitment to notify us of security incidents affecting our data within a defined time. State the time. Must-have
S8 A HIPAA business associate agreement where captured traffic may contain protected health information, and FedRAMP authorization or FIPS 140-3 validated cryptography for public-sector use. Make these Must-have where they apply to you. Nice-to-have

Implementation and support

ID Requirement Priority
M1 A site survey and sensor placement design showing where traffic will be collected, how many sensors each site needs and which networks won't be covered, delivered as a written document. Must-have
M2 A phased rollout plan: visibility first, then risk and remediation, then segmentation in simulation mode, then staged enforcement, with named roles and the effort expected from both sides. Must-have
M3 Identification of who delivers the implementation (vendor, partner or both), the named team's experience in environments like ours, and how work on OT or clinical networks will follow our change-control process. Must-have
M4 A classification tuning period with agreed targets for unknown and misclassified devices, and a stated turnaround for adding device types the product doesn't yet recognize. Must-have
M5 A service-level agreement for availability of the management service, with service credits, and 24×7 support for critical issues with response-time targets by severity. State the targets. Must-have
M6 Regular updates to the device classification library, vulnerability data and detections, with advance notice of changes that affect risk scores or enforcement policy. Must-have
M7 Training and runbooks for our security operations, network and device-owner teams, plus a named customer success contact and periodic risk reviews. Nice-to-have

Commercial and pricing

ID Requirement Priority
C1 Pricing broken down by metric (per device, per site or per sensor) and term, showing list price, discount and net price. Define exactly which devices count, including managed IT devices, guest or transient devices and devices behind gateways. Must-have
C2 Sensor hardware costs, whether purchased or included in the subscription, plus hardware support, replacement and refresh terms. Must-have
C3 Separate prices for optional modules, such as OT coverage, medical device coverage, enforcement integrations and vendor-managed monitoring. Must-have
C4 Growth terms: how increases in device count are measured and billed, and prices for adding devices, sites or modules mid-term, co-terminated with the main agreement. Must-have
C5 A cap on price increases at renewal, covering the subscription and any modules. State the cap. Must-have
C6 A proof of value at no charge, with loaned sensors and the vendor's engineering support. Nice-to-have
C7 Exit terms covering export of the device inventory, classifications, communication maps, policies and history in a usable format, plus transition assistance. Must-have

Questions to ask IoT Security vendors

These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.

  1. From the traffic captured during the proof of value, show your inventory for that site: how many devices are classified to manufacturer, model and firmware version, how many only to a device type, and how many are unknown. How are unknown device types added to your library, and how long does that take?
  2. Which of your discovery methods send packets to devices? For each one, which device types are excluded by default, and how have you tested that it is safe for fragile devices such as industrial controllers, medical devices and older building controllers?
  3. When a device's firmware version can't be seen in its traffic, how do you decide which vulnerabilities apply to it, and how do you show an analyst the confidence of that match?
  4. Walk us through the risk score for one of our devices. Which factors carry the most weight, and can we adjust them for our environment?
  5. Take one device group, such as IP cameras, from observed traffic to an enforced segmentation policy: the recommendation, the simulation and the change in our [NAC or firewall]. Which steps are manual?
  6. Which enforcement actions does your product take itself, and which depend on our NAC, firewalls or switches? What happens to quarantined devices if your management service or our NAC becomes unavailable?
  7. Based on our network diagrams, where would you place sensors at our [number] sites, and what would we not see at sites where we can't mirror traffic?
  8. Exactly what data leaves our network: metadata, packet payloads or full captures? Where is it stored, for how long, and can we turn off payload capture for clinical or OT networks?
  9. How do you handle devices that change IP address, wireless devices that randomize their MAC address, and devices seen at more than one site? Show how one device is matched with its records from our EDR, MDM and CMDB.
  10. Show an alert raised for a device behaving outside its baseline. What evidence does the analyst see, what tuning did a customer of our size need after deployment, and how are false positives suppressed?
  11. For OT networks: which industrial protocols do you decode deeply enough to see controller program changes and commands, and which do you identify only by port? Demonstrate detection of a controller program download.
  12. For medical devices: how do you identify clinical devices, link them to manufacturer disclosures and recalls, and coordinate containment with clinical engineering so that patient care isn't disrupted?
  13. How are devices counted for licensing? Show the billable count your product would produce for the proof-of-value site, and explain how managed laptops, guest devices and devices behind gateways are treated.
  14. Which capabilities in your proposal need a separate module, a partner product or a minimum sensor version, and which are in preview or on the roadmap? Give general-availability dates.
  15. Provide a reference customer of similar size and industry that has moved from visibility to enforced segmentation of IoT devices with your product. What took longest, and why?

Scoring rubric

Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.

Criterion Weight What a strong response shows
Discovery and classification depth 25% Finds the devices in your hand-verified sample during the proof of value, classifies them to model and firmware, leaves few unknowns, and has a clear process for adding new device types.
Risk and vulnerability context 15% Vulnerability matches you can trust, known-exploited flags, risk scores that explain themselves, and remediation tracking with device owners.
Segmentation and enforcement 15% Policy recommendations from observed traffic, a working simulation mode, and enforcement demonstrated through your own NAC and firewalls.
Threat detection and alert quality 10% Behavior-based detections with clear evidence, a manageable alert volume after tuning, and OT or medical device detections where you need them.
Deployment fit and data handling 10% Sensors that fit your network, passive-only operation where required, coverage for small sites, and a clear account of what data leaves your network.
Integration, implementation and support 10% Pre-built integrations with your NAC, firewalls, SIEM, ITSM and CMDB, a usable API, a phased rollout plan and clear support targets.
Commercials and total cost 15% A clear device-counting rule, transparent sensor and module pricing, fair growth and renewal terms, and a three-year view that includes hardware.
Total 100%

Scoring scale

  • 5 Exceeds: meets every Must-have and most Nice-to-haves, shown in a demo or proof of concept, with a matching reference customer.
  • 4 Strong: meets every Must-have and some Nice-to-haves, with clear evidence.
  • 3 Adequate: meets most Must-haves; gaps have a credible workaround or a dated roadmap commitment.
  • 2 Weak: misses one or more Must-haves, or the answer is vague.
  • 1 Poor: does not meet the requirement, or no answer.

Frequently asked questions

What should an IoT security RFP include?

Your scope (sites, networks and the device types you know about); requirements for discovery, device profiling, vulnerability context, risk scoring, threat detection and segmentation, each marked Must-have or Nice-to-have; optional requirements for OT and medical devices; integration with your NAC, firewalls, SIEM and CMDB; data handling, support and SLA terms; a pricing table with a clear device-counting rule; and the rubric you'll score with. This template includes all of them. If you build connected products rather than run them, you need product security tools (firmware analysis, SBOM management, secure updates) and a different RFP.

How do you secure IoT devices that can't run an agent?

Many connected devices, such as cameras, printers, building controllers, medical equipment and industrial controllers, can't run endpoint security software, and some can't be patched quickly or at all. IoT security platforms protect them without an agent: they identify each device from its network traffic, show its vulnerabilities and risky behavior, and limit what it can reach through segmentation enforced by your NAC, firewalls or switches. Where a device can't be patched, segmentation and monitoring become the compensating controls.

What is the difference between IoT security and NAC?

Network access control (NAC) decides whether a device may join the network and which VLAN or policy it gets, and many NAC products include basic device profiling. An IoT security platform goes deeper into what each device is and does: model and firmware, known vulnerabilities, communication patterns and abnormal behavior. The two normally work together, with the IoT security platform supplying classification and risk and the NAC or firewall enforcing access, so this template asks how each vendor integrates with the enforcement tools you already run.

Do we need separate security tools for IoT, OT and medical devices?

Not necessarily. Many products now cover IoT, OT and medical devices from one inventory, sometimes sold as cyber-physical systems (CPS) security, often with OT and medical capabilities licensed as separate modules. Specialist products can go deeper in one environment, for example by decoding more industrial protocols or tracking medical device recalls. If OT or clinical networks are in scope, raise requirements F15 or F16 to Must-have and test them on those networks during the proof of value.

How long does an IoT security RFP take?

The example schedule in this template runs about 12 weeks from kickoff to contract award, including three weeks for vendor responses and three to four weeks for a proof of value. Allow more time if OT or clinical networks need change approval before sensors are connected, or if the proof of value covers several sites. Rollout follows the award in phases, starting with visibility and moving to enforcement once policies have been tested.

Related RFP templates

Download Template

More cybersecurity templates