NAC proposals all promise 802.1X, profiling and posture, and the differences only appear when a bidder has to admit your printers, revoke a certificate in real time or survive a RADIUS outage at a branch. This template is a ready-to-issue request for proposal for a network access control (NAC) platform, with numbered requirements written so that each answer can be tested in a proof of concept and scored. It covers authentication and certificates, profiling of headless devices, posture, enforcement, RADIUS transport security, the platform's own admin and API credentials, operations and pricing. It is vendor-neutral and written for network architects, security and identity teams, procurement and evaluation panels. Read the Network Access Control Buyer's Guide first for evaluation criteria and the Network Access Control (NAC) Guide for how the protocols work; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [MDM], [EDR], [SIEM] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example NAC-AUT-03) and a type: M mandatory (pass or fail), S scored (weighted 0 to 5) or I informational. Keep M items few, or every bidder fails something.
- Device counts, timings and weights in brackets are illustrative. Run discovery for at least two weeks before issue so Appendix A reflects what actually connects, including devices that appear only at month end or during maintenance.
- Issue sections 1 to 8 and Appendix A to bidders. Implementation guidance is for the panel only. Ask for responses in a spreadsheet with one row per requirement ID and a documentation link for every "available now" answer.
1. Purpose and scope
[Organisation] invites proposals for a network access control platform that authenticates and authorises every device and user connecting to wired, wireless and [VPN] networks at [number] sites, assigns network access by policy, and removes or restricts access when a device's identity or compliance changes. The platform must support [on-premises / cloud-delivered / hybrid] RADIUS service. Out of scope: [for example firewall replacement, SASE, guest Wi-Fi hardware].
2. Current state
- Network estate: switch and wireless controller vendors, models and software versions in Appendix A; [number] sites, of which [number] have a single WAN link.
- Identity sources: [on-premises directory / cloud identity provider]; machine and user authentication [both required / user only].
- PKI: [private CA name or "none"]; device certificates issued through [MDM] using [SCEP / PKCS / ACME]. See the Machine Identity, PKI and Certificate Lifecycle Guide.
- Posture sources: [MDM], [EDR], [vulnerability scanner].
- Current access control: [open ports / MAC filtering / existing NAC in monitor mode]; current RADIUS servers and shared-secret practice.
- Regulated or sensitive segments: [OT cells, clinical devices, payment networks], with any rule that forbids active scanning.
3. Instructions to bidders
- Timeline: RFP issued [date]; questions by [date]; responses due [date, time, time zone]; proof of concept [dates]; decision [date].
- Contact: [name, email]; other contact about this RFP may lead to disqualification.
- Response scale: available now; available with configuration; custom development; third-party product required (name it); roadmap (committed date); not supported. Roadmap answers score zero unless contractually committed.
- Compatibility evidence: for every switch and wireless model in Appendix A, state which enforcement features (dynamic VLAN, downloadable ACLs, group tags, Change of Authorization) you have tested, on which software version.
4. Functional requirements
4.1 Authentication and certificates
| ID | Requirement | Type |
|---|---|---|
| NAC-AUT-01 | Acts as RADIUS server and EAP server for IEEE 802.1X-2020 port-based network access control on wired and wireless networks. | M |
| NAC-AUT-02 | Supports EAP-TLS, including EAP-TLS 1.3 as specified in RFC 9190, with OCSP stapling and revocation checks on every certificate in the client chain except the trust anchor. | M |
| NAC-AUT-03 | Supports machine and user authentication on the same session (for example with TEAP), and policy that distinguishes a managed device with no user from a user on an unmanaged device. | S |
| NAC-AUT-04 | Describe how certificate-based identities are matched to directory or MDM records (for example a device ID in the certificate subject alternative name) and what happens when no match is found. | M |
| NAC-AUT-05 | Password-based EAP methods and MAC Authentication Bypass (MAB) can be limited by policy to named device groups, network locations and VLANs, and every MAB admission is logged with the matched profile. | M |
| NAC-AUT-06 | State whether the platform can issue, renew and revoke device certificates itself or integrates with [CA], and the behaviour when a certificate expires or is revoked mid-session. | S |
| NAC-AUT-07 | Supports hardware-bound device identities (IEEE 802.1AR IDevID or LDevID) for devices that present them. | I |
See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide.
4.2 Profiling and headless devices
| ID | Requirement | Type |
|---|---|---|
| NAC-PRO-01 | Classifies devices passively from DHCP, LLDP, CDP-style discovery, HTTP user agent and traffic attributes, with a confidence score per classification. | M |
| NAC-PRO-02 | Active probing (SNMP, port scans) can be disabled per network segment and is off by default on segments listed as passive-only in Appendix A. | M |
| NAC-PRO-03 | Devices below [confidence threshold] or unknown devices receive a restricted policy, never default corporate access. | M |
| NAC-PRO-04 | Detects MAC spoofing indicators, such as a profiled printer that starts behaving like a workstation, and can trigger reauthentication or quarantine. | S |
| NAC-PRO-05 | Customers can add their own profiles for OT, medical and specialist devices; state the library update frequency. | S |
| NAC-PRO-06 | Consumes Manufacturer Usage Description (MUD) URLs as defined in RFC 8520 where devices emit them. | I |
| NAC-PRO-07 | Describe handling of randomised MAC addresses on mobile and laptop operating systems. | M |
See the Device and IoT Identity Guide.
4.3 Posture and compliance
| ID | Requirement | Type |
|---|---|---|
| NAC-POS-01 | Retrieves device compliance from [MDM] and health from [EDR] by API and uses it in policy; state the polling interval or event mechanism. | M |
| NAC-POS-02 | A change in compliance after admission changes the session's access within [10 minutes] using RADIUS Change of Authorization. | M |
| NAC-POS-03 | If an agent is offered, list supported operating systems, checks (encryption, OS version, firewall, EDR running) and how the agent's own update channel is secured. | S |
| NAC-POS-04 | Non-compliant devices are moved to a remediation network with access only to [MDM, patch and help desk services], with a message to the user. | S |
4.4 Enforcement and segmentation
| ID | Requirement | Type |
|---|---|---|
| NAC-ENF-01 | Assigns access by dynamic VLAN, downloadable ACL or group tag on the network equipment in Appendix A. | M |
| NAC-ENF-02 | Sends CoA-Request and Disconnect-Request messages (RFC 5176) to change or end sessions, and records the acknowledgement or failure. | M |
| NAC-ENF-03 | Accepts quarantine requests from [SIEM / SOAR / EDR] through an authenticated API, with an approval option and automatic expiry. | S |
| NAC-ENF-04 | Supports monitor (open), low-impact and closed modes per port group, site or SSID, with a documented way to return any scope to open mode within [15 minutes]. | M |
| NAC-ENF-05 | Shares session identity (user, device, group) with [firewalls / SASE] for identity-aware policy. | S |
| NAC-ENF-06 | Guest and contractor onboarding with sponsor approval, time-limited credentials and separate network access. | S |
See the Network Segmentation Guide.
5. Platform security and non-functional requirements
The NAC platform decides who reaches the network, so its RADIUS secrets, admin accounts and API tokens are among the most sensitive credentials in the estate. These requirements carry heavy weight in scoring.
| ID | Requirement | Type |
|---|---|---|
| NAC-SEC-01 | Mitigates Blast-RADIUS (CVE-2024-3596): requires and validates the Message-Authenticator attribute on all RADIUS requests and responses, and can reject packets without it per client. | M |
| NAC-SEC-02 | Supports RADIUS over TLS (RFC 6614, TCP port 2083) or another authenticated, encrypted transport between network devices and RADIUS servers; state which network device models in Appendix A you have tested. | S |
| NAC-SEC-03 | Supports a unique shared secret per network device, secrets of at least [32] random characters, and secret rotation without outage. | M |
| NAC-SEC-04 | Admin console uses SSO with [identity provider] and phishing-resistant MFA, with role-based admin separating policy authoring, device onboarding, help desk lookup and audit. | M |
| NAC-SEC-05 | API and integration credentials (MDM, EDR, SIEM, directory) are scoped to the minimum permissions, stored encrypted, listed in an inventory with owner and last use, and rotatable. Directory bind accounts must not need administrative rights. | M |
| NAC-SEC-06 | Every policy change, admin login and quarantine action is logged with actor and time and exported to [SIEM] in [syslog / API] format; authentication logs include failure reasons. | M |
| NAC-SEC-07 | For cloud-delivered service: hosting regions, sub-processors, current independent assurance reports, tenant isolation and the security incident notification period to customers. | M |
| NAC-SEC-08 | Publishes security advisories and a vulnerability disclosure policy; state patch timelines for critical issues. | S |
| NAC-NFR-01 | High availability: state the failover behaviour, the re-authentication load after a node fails, and the tested authentication rate per node. | M |
| NAC-NFR-02 | Site survivability: describe access behaviour at a site that loses its link to central or cloud RADIUS service (cached policy, local fallback, critical VLAN). | M |
| NAC-NFR-03 | Upgrades without authentication outage, with documented rollback. | S |
See the RADIUS Security Guide.
6. Services and support
- [NAC-SVC-01] Proposed implementation plan by site wave, with named roles, monitor-mode duration and exit criteria per wave.
- [NAC-SVC-02] Support hours, severity definitions and response times; escalation for authentication outages.
- [NAC-SVC-03] Admin training and runbooks for help desk staff troubleshooting failed authentication.
- [NAC-SVC-04] Personnel who access our environment during implementation use named accounts with MFA, and access is removed at handover.
7. Pricing
- Price against Appendix A at current volumes and at [+25%] and [+50%] devices, over [three / five] years.
- State the licence metric (concurrent sessions, endpoints, devices profiled, sites) and how headless and guest devices are counted.
- List any capability in sections 4 and 5 that needs an additional licence or module, including posture, profiling and certificate issuance.
- State hardware or virtual appliance costs, support renewal uplift caps and exit assistance at contract end.
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Authentication and certificate lifecycle (4.1) | [20%] | EAP-TLS on managed platforms, revocation test |
| Profiling of headless devices (4.2) | [20%] | Classification rate on our device sample |
| Posture and enforcement (4.3, 4.4) | [20%] | Time from non-compliance to restricted access |
| Platform security (5) | [15%] | RADIUS protection, admin and API controls, assurance |
| Operations and resilience (5, 6) | [10%] | Failover test, monitor mode reporting, logs |
| Cost over the term (7) | [15%] | Priced against Appendix A at three volumes |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated in the proof of concept. Shortlisted bidders will run a [four]-week proof of concept covering:
- Run in monitor mode on [two] sites and compare the discovered inventory with our asset inventory.
- Authenticate managed [Windows, macOS, iOS, Android] devices with EAP-TLS; revoke one certificate and confirm access ends within the agreed time.
- Classify at least [20] headless device types; record correct, wrong and unknown classifications and time to profile.
- Mark a device non-compliant in [MDM] and raise a test alert in [EDR]; time the move to the remediation network.
- Send RADIUS packets without Message-Authenticator from a test switch and confirm they are rejected.
- Fail one RADIUS node and cut one pilot site's WAN link during working hours; observe re-authentication and site behaviour.
- Move one pilot port group to closed mode, then return it to open mode using the documented rollback, and time it.
- Export one day of authentication and admin audit logs to [SIEM].
Appendix A: estate and device population
| Site or segment | Network equipment and version | Device classes and counts | Supplicant capable | Active probing allowed |
|---|---|---|---|---|
| [HQ campus wired] | [switch model, version] | [laptops, printers, phones] | [%] | [yes / no] |
| [Office wireless] | [controller or cloud AP, version] | [laptops, mobiles, BYOD] | [%] | [yes / no] |
| [Plant or clinical network] | [ ] | [PLCs, HMIs, infusion pumps] | [%] | [no] |
| [Branch with single WAN link] | [ ] | [ ] | [%] | [ ] |
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Fix discovery before issue: the hardest NAC requirement to meet is admitting devices you did not know about. Two weeks of switch, DHCP and wireless data in Appendix A saves months of exceptions later.
- Test your own switches: CoA, downloadable ACLs and group tags depend on network equipment models and versions. A bidder's answer is only as good as the compatibility evidence under section 3, item 4.
- Treat MAB as an exception register: every MAB-admitted class needs an owner, a restricted policy and a review date. NAC-AUT-05 and NAC-PRO-03 are what stop a spoofed MAC from inheriting a printer's access.
- Protect the platform from day one: issue bidders time-limited, least-privilege proof of concept accounts and integration credentials, revoke them afterwards, and do not reuse production RADIUS secrets on test switches. See the NHI Security Platform RFP Template for credential inventory requirements.
- Keep a rollback switch: our recommendation is that no site moves from monitor to closed mode without a tested return to open mode (NAC-ENF-04) and help desk runbooks in place.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Authentication and certificates (4.1) | IA-3, IA-3(1), IA-5, AC-18(1) | PR.AA-01, PR.AA-03 |
| Profiling and inventory (4.2) | CM-8 | ID.AM-01 |
| Posture and enforcement (4.3, 4.4) | AC-3, AC-19, SC-7 | PR.AA-05, PR.IR-01 |
| Platform security and logging (5) | SC-8(1), AC-6, AU-2, AU-9 | PR.PS-01, DE.CM-01 |
| Acquisition (all) | SA-4 | GV.SC-05 |
Standards and references
- IEEE: 802.1X-2020 Port-Based Network Access Control
- IETF: RFC 9190 EAP-TLS 1.3
- IETF: RFC 5176 Dynamic Authorization Extensions to RADIUS
- IETF: RFC 6614 TLS Encryption for RADIUS
- IETF: RFC 8520 Manufacturer Usage Description Specification
- Blast-RADIUS research team: RADIUS/UDP considered harmful
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Network Access Control (NAC) Guide · Network Access Control Buyer's Guide · RADIUS Security Guide · Device and IoT Identity Guide · Certificate Lifecycle Management RFP Template