Unified endpoint management RFPs usually ask how many operating systems a platform supports and miss the question that matters most: what one compromised administrator account can do to every device you own. This template gives you a ready-to-issue request for proposal for a unified endpoint management (UEM) platform covering Windows, macOS, iOS and iPadOS, Android and [Linux] devices, corporate owned and personally owned. Requirements are numbered, typed and written so that each answer can be tested in a proof of concept and scored: zero-touch enrolment, configuration and compliance, patching and application management, device trust signals for access decisions, administrative safeguards, APIs and pricing per device or per user. It follows NIST SP 800-124 Rev. 2 for the device lifecycle and is vendor-neutral. It is written for endpoint engineering leads, security architects and procurement. For the market view, read the UEM Buyer's Guide; for the selection process, the Security Vendor Evaluation and RFP Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [device counts] and [identity provider], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example UEM-AS-03) and a type: M mandatory (pass or fail; a fail eliminates the bid), S scored (0 to 5, weighted) or I informational.
- Weights, counts and service levels in brackets are illustrative. Set them before issue and do not change them after responses arrive.
- Keep the administrative safeguard requirements in section 5 as mandatory. A UEM console is a software deployment tool with the power to wipe or reconfigure the whole estate; treat it as a tier zero system.
- Issue sections 1 to 9 to bidders. The Implementation guidance section is for your evaluation panel only.
- Ask for responses in a spreadsheet with one row per requirement ID and per operating system, with a documentation link for every "available now" answer.
1. Purpose and scope
[Organisation] invites proposals for a unified endpoint management platform and associated services, to enrol, configure, secure, update and retire endpoints used by [number] staff and [contractors, frontline workers, shared devices, kiosks].
- In scope: device enrolment and inventory; configuration profiles and baselines; compliance policies and remediation; operating system and third-party application patching; application deployment and app protection; device trust signals to [identity provider]; remote lock, wipe and retirement; reporting, APIs and audit.
- Out of scope: [endpoint detection and response, procured separately]; [endpoint privilege management]; [service desk tooling].
- Drivers: [consolidation of separate mobile and desktop tools]; [move from on-premises management]; [audit findings on patch latency]; [device-based access requirements].
- Contract term: [three] years with an option to extend by [two].
2. Organisation background and current state
| Item | [Organisation] value |
|---|
| Devices by operating system and ownership | Windows [n], macOS [n], iOS and iPadOS [n], Android [n], Linux [n]; corporate [n], personally owned [n] |
| Users and devices per user | [number] users, average [number] devices |
| Current management tools | [tools and versions], [Group Policy, on-premises configuration management] |
| Identity provider and directory | [identity provider], [directory] |
| Locations and network constraints | [sites], [low bandwidth or offline sites], [countries] |
| Security tools that consume device signals | [EDR], [SIEM], [conditional access], [vulnerability management] |
| Regulatory or contractual baselines | [CIS Benchmarks level], [sector rules], [customer contract terms] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; answers shared with all bidders by [date]; responses due [date, time, time zone]; demonstrations and proof of concept [dates]; decision [date].
- Single point of contact: [name, email].
- Response scale: per requirement and per operating system state available now, available with configuration, requires scripting, third-party product required, roadmap (committed date) or not supported. Roadmap answers score zero unless the date is contractual.
- Evidence: cite the documentation page for each answer and the licence tier or add-on it requires. Where a capability depends on an operating system vendor's management framework, say which framework and which minimum OS version.
4. Functional requirements
4.1 Enrolment and inventory
| ID | Type | Requirement |
|---|
| UEM-EN-01 | M | Zero-touch enrolment for corporate devices using each operating system vendor's automated enrolment programme, so that a new or wiped device enrols on first boot without IT handling. |
| UEM-EN-02 | M | Enrolment requires user authentication through [identity provider] with MFA; enrolment of devices not registered to [Organisation] can be blocked. |
| UEM-EN-03 | S | Personally owned device enrolment that separates work and personal data (work profile or user enrolment) and gives IT no visibility of personal apps, location or content. |
| UEM-EN-04 | S | Hardware and software inventory refreshed at least every [24] hours, with serial, model, OS build, encryption state, installed software and last check-in, exportable by API. |
| UEM-EN-05 | S | Shared device and kiosk modes with single app or multi-app lock-down and session clean-up between users. |
| UEM-EN-06 | S | Detection and reporting of stale devices (no check-in for [days]) and devices in inventory but not in [identity provider], and the reverse. |
4.2 Configuration and compliance
| ID | Type | Requirement |
|---|
| UEM-CF-01 | M | Enforcement of full-disk encryption with recovery keys escrowed in the platform, access to recovery keys restricted by role and logged. |
| UEM-CF-02 | S | Security baselines mapped to [CIS Benchmarks] or equivalent for each OS, with drift reporting and automatic re-application. |
| UEM-CF-03 | S | Declarative or state-based management where the OS supports it, so devices report status changes without polling. |
| UEM-CF-04 | S | Compliance policies (OS version, encryption, firewall, screen lock, jailbreak or root, EDR running) with grace periods and staged actions: notify, restrict, block, retire. |
| UEM-CF-05 | S | Local administrator password management on Windows and macOS: unique, rotated passwords retrieved through the console with logging. See the Endpoint Privilege Management Guide. |
| UEM-CF-06 | S | Certificate deployment for Wi-Fi, VPN and device identity using SCEP or ACME with [certificate authority], with renewal before expiry. |
4.3 Patching and applications
| ID | Type | Requirement |
|---|
| UEM-PA-01 | M | Operating system update control with deployment rings, deferral and deadline settings, and reporting of devices behind the target build. |
| UEM-PA-02 | S | Third-party application patching for a published catalogue of at least [number] titles, with custom package support and the catalogue update service level stated. |
| UEM-PA-03 | S | Emergency patch deployment to all devices within [hours], with completion reporting suitable for a known exploited vulnerability deadline. |
| UEM-PA-04 | S | Application deployment from public stores and internal sources, with allow and block lists and removal of unauthorised applications. |
| UEM-PA-05 | S | App protection policies for unenrolled mobile devices: block copy to personal apps, require app PIN, selective wipe of work data. |
| UEM-PA-06 | S | Scripts and packages deployed by the platform are signed or hashed, reviewed before release, and their execution logged per device. |
See the Patch Management Guide for ring design and service levels.
4.4 Device trust and integrations
| ID | Type | Requirement |
|---|
| UEM-DT-01 | M | Device compliance state shared with [identity provider] for conditional access decisions within [minutes] of a change. |
| UEM-DT-02 | S | Device identity bound to hardware (for example a TPM or secure enclave key) so a compliance claim cannot be copied to another device. |
| UEM-DT-03 | S | Bidirectional integration with [EDR]: risk level from EDR drives compliance, and UEM deploys and verifies the EDR agent. |
| UEM-DT-04 | S | Documented REST API covering inventory, compliance, actions and audit, with webhooks or event streaming to [SIEM]. |
See the Device Trust and Posture Guide and the Conditional Access Guide.
4.5 Lifecycle and retirement
| ID | Type | Requirement |
|---|
| UEM-LC-01 | S | Remote lock, selective wipe of work data and full wipe, with confirmation of completion per device. |
| UEM-LC-02 | S | Automated offboarding triggered by [HR system or identity provider]: revoke access, selective wipe of personally owned devices, retire corporate devices. |
| UEM-LC-03 | S | Lost device workflow and release of activation locks so devices can be reissued. |
| UEM-LC-04 | I | Describe how the platform supports media sanitisation evidence when devices are disposed of. |
These requirements address the risk that a single stolen administrator identity is used to wipe or reconfigure the estate, as in a March 2026 wiper attack where a compromised administrator account created a new top-level administrator and issued mass remote wipes through the management console, without any wiper malware on the endpoints.
| ID | Type | Requirement |
|---|
| UEM-AS-01 | M | Multi-administrator approval for destructive and high-impact actions (wipe, retire, bulk script deployment, role changes, compliance policy changes), configurable by action and by device count. |
| UEM-AS-02 | M | Hard limits or rate controls on bulk wipe and retire actions, with an alert and a pause when a threshold of [number] devices in [minutes] is reached. |
| UEM-AS-03 | M | Granular role-based access scoped by device group, operating system and action; no requirement for a global administrator for daily tasks. |
| UEM-AS-04 | M | Console sign-in only through [identity provider] with phishing-resistant MFA; local console accounts disabled or limited to a documented break-glass account. |
| UEM-AS-05 | S | Immutable audit log of every administrative action and API call, retained for [days] and streamed to [SIEM] in near real time. |
| UEM-AS-06 | S | API clients and service principals scoped to the least permissions needed, with credential expiry, rotation and an inventory of every integration holding UEM permissions. |
| UEM-AS-07 | M | Independent assurance: [ISO/IEC 27001 certificate and SOC 2 Type II report], penetration test summary, and data residency in [regions]. |
| UEM-AS-08 | S | Vendor support access to the tenant requires customer approval, is time-bound and logged. |
UEM API credentials can push code to every device. Manage them as described in the Service Account Security Guide.
Vendor security questions
- Which administrative actions can be placed behind multi-administrator approval today, and which cannot?
- What prevents a compromised administrator from disabling multi-administrator approval or the bulk action threshold itself?
- How are your own engineers' access to the production service and to customer tenants controlled, reviewed and logged?
- How are agent binaries and platform-delivered scripts signed, and how would a customer detect a tampered update?
- Describe any security incident in the last [three] years that affected customer tenants, and the notification you gave.
- How quickly are vulnerabilities in the device agent and console fixed, and how are customers told?
- Which subprocessors handle device inventory, location or recovery key data, and in which countries?
- What audit evidence do you supply to show that recovery keys and local administrator passwords were accessed only by authorised roles?
6. Scale, availability and operations
| ID | Type | Requirement |
|---|
| UEM-OP-01 | M | Contractual availability of at least [99.9%] for the console and device check-in service, with service credits and status history. |
| UEM-OP-02 | S | Content delivery that works for [remote and low bandwidth sites], including peer caching or local distribution options. |
| UEM-OP-03 | S | Support for new OS releases on the day of general availability, with the vendor's historical record for the last [three] releases. |
| UEM-OP-04 | S | Reporting dashboards and scheduled exports for compliance rate, patch latency and inventory accuracy. |
7. Migration, implementation and support
- UEM-MI-01 (S): migration plan from [current tools], including re-enrolment approach for devices that cannot be migrated in place.
- UEM-MI-02 (S): conversion of existing Group Policy or configuration baselines, with a gap report.
- UEM-MI-03 (S): named implementation staff and [number] references with similar device mix.
- UEM-MI-04 (S): support tiers, severity definitions and response times, including weekend cover.
- UEM-MI-05 (M): exit: export of inventory, configuration and audit data in a documented format, and a supported path to unenrol devices without wiping them.
8. Pricing schedule
| Cost element | What to state |
|---|
| Pricing metric | Per device or per user, how many devices a user licence covers, how shared devices and kiosks are counted |
| Tiers and add-ons | Which requirements need a higher edition or add-on (for example third-party patching, multi-admin approval, remote assistance) |
| Growth model | Total cost at [current], [1.5x] and [2x] devices over the term; cap on renewal increases |
| Services | Implementation and migration price, day rates and estimated days |
| Hidden costs | Infrastructure for on-premises components, connectors, content delivery |
9. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|
| Administrative safeguards and platform security (5) | [20%] | Demonstration of multi-admin approval and bulk limits |
| Enrolment, configuration and compliance (4.1, 4.2) | [20%] | Proof of concept on each OS |
| Patching and applications (4.3) | [20%] | Patch latency and catalogue test |
| Device trust and integrations (4.4) | [10%] | Conditional access test |
| Operations and migration (6, 7) | [10%] | Plan, references |
| Three-year cost (8) | [20%] | Pricing schedule |
Scores: 0 not met; 1 roadmap only; 3 met with configuration; 5 met and demonstrated. Shortlisted bidders run a proof of concept of [number] weeks on test devices:
- Zero-touch enrol one new device per OS and record time from first boot to compliant.
- Enrol a personally owned phone and confirm what IT can and cannot see.
- Apply a baseline, change a setting locally and measure detection and re-application time.
- Deploy an OS update by ring and a third-party patch; record completion reporting.
- Break compliance (disable encryption or EDR) and confirm conditional access blocks the device within the stated time.
- Attempt a bulk wipe of the test group from a scoped administrator account; confirm a second approver is required and the threshold alert fires.
- Export audit logs to [SIEM] and confirm every step above is recorded.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Test per operating system: a "yes" for a feature on one OS is often a "partial" on another. Score per OS row and weight by your device mix.
- Treat the console as tier zero: the UEM can run code and wipe every device (ATT&CK T1072 Software Deployment Tools, T1485 Data Destruction through T1078 Valid Accounts). Score section 5 as heavily as features.
- Check licence tiers line by line: safeguards such as multi-admin approval or third-party patching often sit in a higher tier. Price the configuration you will actually run.
- Plan migration early: re-enrolment is the largest hidden cost. Ask for a gap report on baseline conversion before contract.
- Protect personal privacy: staff adoption of personally owned enrolment depends on clear limits on what IT can see; publish them.
Common failure patterns
- Global administrators for daily work: broad roles turn one phished account into an estate-wide wipe.
- No bulk action limits: wipe and script deployment run against thousands of devices with no second approver.
- Unmanaged API credentials: integrations hold write permissions with secrets that never expire.
- Inventory drift: devices missing from the UEM never receive patches and never appear in compliance reports.
- Feature parity assumed: requirements scored once for all OSs, then found missing for macOS or Linux after contract.
Framework mapping
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|
| Enrolment and inventory (4.1) | CM-8 | ID.AM-01 |
| Configuration and compliance (4.2) | CM-2, CM-6, AC-19 | PR.PS-01 |
| Patching and applications (4.3) | SI-2, CM-7 | PR.PS-02 |
| Retirement (4.5) | MP-6 | PR.PS-02 |
| Administrative safeguards (5) | AC-2, IA-2, AU-6 | PR.AA-02, DE.CM-09 |
| Supplier assurance (5, 7) | SA-9, SR-6 | GV.SC-06 |
Standards and references
Related NHI Mgmt Group resources: UEM Buyer's Guide · Endpoint Security Guide · Mobile Device Security Guide · EDR and XDR RFP Template · Endpoint Hardening Checklist