By Spencer James, HighGround Exchange · Updated · Sources & methods
Carrier-led and device-led programmes optimise different things
A carrier programme centres on connectivity, financing devices and support inside a network agreement, which suits organisations whose main problem is coverage, plan structure and the number of lines. A device-led programme centres on the hardware lifecycle, standardising models, imaging, warranty and break-fix, and adds connectivity alongside. The two are not competing products so much as different starting points, and the starting point should be your actual constraint: a dispersed field workforce with little office time is a coverage and plan problem, while a managed office estate refreshing on a fixed cycle is a lifecycle problem. Before either programme is scoped, settle whether devices are financed inside the plan or held as assets, who owns the device at the end of the term, and whether data is pooled across the fleet or charged per line.
- Identify whether coverage or lifecycle control is the binding constraint.
- Check whether devices are financed inside the plan or held as assets.
- Confirm who owns the device at the end of the term.
- Establish whether data plans are pooled, per user or per device.
The device security baseline is published, and personal devices are a second policy
A mobile-device policy that cannot be pointed at a published standard is difficult to defend to an insurer, an auditor or a customer's security review. The reference to use is NIST SP 800-124 Revision 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise, published in May 2023. It covers both organisation-provided and personally owned devices, follows a device through deployment, use and disposal, and describes centralised device management and endpoint protection as the mechanisms that carry the policy. The companion access-control split sits in NIST SP 800-53 Revision 5. AC-19, Access Control for Mobile Devices, asks for configuration requirements, connection requirements and implementation guidance for organisation-controlled mobile devices, including when those devices are used outside controlled areas, and for the authorisation of any device connecting to organisational systems. AC-20, Use of External Information Systems, covers a different case: the terms and conditions under which an authorised person may reach your systems from an external system, or process, store or transmit your information there. The practical consequence is that a bring-your-own-device arrangement is not an exemption from the policy but a second policy with its own conditions, and the two cases are governed by different controls with different wording.
- Name the standard the policy follows, and its revision.
- Write separate rules for organisation-owned and personal devices.
- State configuration and connection requirements rather than a general expectation.
- Say who authorises a device to connect, and how that authorisation is withdrawn.
Enrolment and tracking have to be designed for devices that leave the building
Those controls exist only once a device is under management, and management has to begin at the point of ordering rather than in an employee's first week. The enrolment route differs by platform but the principle does not: a device should arrive already enrolled, with policy applied, and should never be handed over in an unmanaged state. Android Enterprise offers several routes for organisation-owned devices — zero-touch, NFC, an EMM token or a QR code — which lets a batch be provisioned by the supplier rather than one device at a time. Apple's equivalent is Automated Device Enrollment, run through Apple Business Manager, which supervises and configures organisation-owned devices automatically at first boot. The SIM has moved the same way. The GSMA's consumer remote-SIM-provisioning specification, SGP.22, is the one behind ordinary eSIM profiles, and SGP.32 extends the model to IoT and machine devices with editions published in July 2023 and April 2024. Those specifications are the carrier's to implement, but the profiles can be managed centrally through a device-management platform: Intune, for example, can add, remove and control eSIM profiles alongside the rest of a device's policy. Devices that leave the building are the harder half, so the assignment record, the enrolment-before-issue rule, configuration that assumes loss, and a return step inside offboarding all have to exist before the fleet grows. Reconciling that record on a schedule is the part that usually fails.
- Enrol at the point of ordering, not in the employee's first week.
- Use the platform's automated enrolment routes rather than manual setup.
- Manage eSIM profiles from the same console as the rest of the device policy.
- Keep an assignment record by person or role, and reconcile it on a schedule.
- Make device return part of offboarding rather than a follow-up.
Multi-carrier eSIM changes what coverage means for a fleet
An embedded SIM is provisioned remotely rather than physically, and modern device management platforms can manage those profiles as part of normal policy. That makes multi-carrier arrangements practical at fleet scale: a device can hold profiles for more than one network and move between them without a physical SIM change, and profiles can be added, suspended or removed centrally, including remote lock and block if a device is lost. For a dispersed fleet this converts coverage from a per-site procurement into a device-level setting, which is the argument for evaluating it alongside the plan rather than after it. What it does not do is fix a site whose problem is wiring rather than mobile coverage, and the steering policy — which network a device prefers, and who controls it — has to be defined rather than left to the handset.
- Check whether your device management platform can manage eSIM profiles.
- Ask how a device steers between networks, and who controls the policy.
- Confirm remote lock and block behaviour for lost devices.
- Establish what happens to profiles when a device leaves the fleet.
Fixed wireless: a primary circuit, a second path, and the spectrum underneath
Wireless access delivered over cellular can carry a whole small site or act as a second path for a larger one, and it is attractive because it avoids construction and the lead time that comes with it. Treating it as a primary circuit and treating it as a backup circuit are different engineering decisions with different requirements. As a primary path it needs its own capacity and latency assessment against the applications actually in use, and a considered position on what happens during a local network incident. As a backup path its value depends on diversity: a second circuit that shares the primary's conduit, provider or exchange is not a diverse path, which is true of wireless and wired alike. Where the wireless capacity comes from also matters, because not all fixed wireless is the same product. One of the bands behind it is the Citizens Broadband Radio Service, set out in 47 CFR Part 96, which shares the 3550–3700 MHz range between three tiers: incumbent users, including federal radiolocation and satellite earth stations, which are protected; Priority Access Licensees holding licensed channels in a defined geographic area; and General Authorized Access users, who may use what remains. Access is coordinated by a Spectrum Access System, and in coastal areas an Environmental Sensing Capability detects incumbent transmissions before the lower tier transmits. A service built on priority or licensed access is a different proposition from one operating opportunistically in shared spectrum, and the question is reasonable to put to a provider.
- Assess capacity and latency against real application use, not a headline speed.
- Define what the circuit is: primary, failover or load-shared.
- Verify diversity against the primary path, not just the provider name.
- Ask which part of the spectrum the service uses and who coordinates access to it.
- Test the failover, including what remains available when it triggers.
The network calendar puts an expiry date on a handset
A mobile device carries a second deadline beyond its own support window: the network it was built for. Cellular capability is defined by 3GPP's releases, and each is frozen on a published date. The functional freeze for Release 15, the first to carry the 5G New Radio specifications, fell on 22 March 2019; Release 16 froze on 3 July 2020, Release 17 on 18 March 2022 and Release 18 in March 2024. A handset's modem implements a particular set of releases, and when a carrier retires a generation of network the device stops working on it whatever condition the hardware is in — so the modem generation belongs in the fleet specification beside the operating system, not in a footnote. The other half of the same problem is the lock. In August 2024 the FCC proposed, in WT Docket No. 24-186, to require all mobile wireless service providers to unlock handsets 60 days after activation unless the provider determines within that window that the handset was bought through fraud. That is a proposal rather than a rule in force, so the operative document is still the provider's own unlock policy — and the question to ask before a fleet commitment is when each device becomes eligible, because a handset financed inside a plan normally stays locked to that carrier until the term ends. A fleet that cannot be moved between networks is a plan decision already made.
- Check the modem generation against the network generations the carrier will still operate.
- Ask when handsets become unlock-eligible, and get it in writing.
- Treat a financed handset as tied to its carrier until the financing term ends.
- Align the handset term with the plan term so both end together.
Numbers and devices are separate assets, and porting runs on a statutory clock
A mobile fleet hides two assets rather than one, and they have different owners. The number is a business asset if the account is the company's, because customers, signage and call records may all point at it; the handset is a physical asset that may be owned, leased or the employee's own. A policy that treats them as one thing produces the familiar outcomes: a departing employee keeps a number customers still call, or a leased handset is written off as a loss because nobody was responsible for collecting it. Moving a number between providers is also not instantaneous, and the interval is set in regulation. Under 47 CFR 52.35 a simple wireline-to-wireline or simple intermodal port must be completed within one business day, and a non-simple port within four business days, unless the new provider or the customer asks for longer. Intermodal covers a wireline-to-wireless port, a wireless-to-wireline port and any port involving interconnected VoIP, so a mobility project that also moves fixed lines or a hosted phone system runs on more than one clock and the cutover plan should say which numbers fall into which interval. Settle four things in writing: who owns a number, and whether anyone is ever permitted to take one with them; how quickly a number is removed or reassigned after a departure date; who confirms that a device has been wiped and whether it is returned, repaired or reassigned; and how eSIM profiles and leased handsets are deactivated in the same step, because all of them continue to cost money while they remain active.
- Treat the number and the device as separate assets with different owners.
- Decide in policy whether a departing employee may keep a number.
- Plan the port against the interval that applies to each number.
- Confirm the wipe or the return rather than assuming it happened.
- Deactivate eSIM profiles and leased handsets in the same step.
What to gather, and how HighGround helps
Bring the current device list with models, ages and plan assignments, a count of users by location and mobility profile, the coverage areas that matter operationally, the current agreement with its end date and per-line structure, and the security standard the business has to satisfy. HighGround sources mobility, devices and connectivity through the AppDirect catalog and scopes each requirement individually. Availability, pricing and terms depend on your locations, the carriers serving them and the contract term, so no two fleets price alike. An inquiry places no order and commits you to nothing, and HighGround may receive compensation from a provider on a completed purchase.
- Device list with model, age, assignment and current plan.
- Users grouped by mobility profile: fixed desk, roaming, field.
- Where coverage actually fails today, described by site.
- Current agreement, term end and how lines are priced.
- The security standard the device policy has to meet.
PUT THE OPTIONS SIDE BY SIDE
Your comparison checklist
| Option | What it optimises | Where it does not help |
|---|---|---|
| Carrier-led programme | Coverage, pooled plans and financed devices | Standardising hardware across a mixed estate |
| Device-led programme | Model standardisation, imaging and warranty | Plan structure and pooled data across a workforce |
| Single-carrier plans | Simplicity and one billing relationship | Coverage gaps in specific buildings or regions |
| Multi-carrier eSIM | Network steering per device without a physical SIM | Sites whose problem is wiring rather than mobile coverage |
| Fixed wireless as primary | Fast deployment without construction | High-capacity or low-latency concentrated sites |
| Fixed wireless as backup | A second path without a second build | Resilience if it shares the primary's failure points |
| Handset financed in the plan | Spreads device cost across the term | Moving the fleet to another network before the term ends |
- A person reads every request and replies within 24 hours.
- Sending an inquiry does not place an order or commit you to anything.
- Availability and terms get confirmed for your locations before anything is decided.
Or call (501) 463-2471
Common questions
Further reading
Provider and official resources for the relevant service categories. Product availability and terms must be confirmed for your request.
NIST — Guidelines for Managing the Security of Mobile Devices in the Enterprise (SP 800-124 Rev. 2) ↗NIST — Security and Privacy Controls for Information Systems (SP 800-53 Rev. 5) ↗Apple — Automated Device Enrollment in Apple Business Manager ↗Android Enterprise — enrollment options for organisation-owned devices ↗3GPP — releases and their functional freeze dates ↗Federal Register — FCC proposed handset unlocking requirement (WT Docket No. 24-186) ↗eCFR — 47 CFR 52.35, porting intervals ↗eCFR — 47 CFR Part 96, Citizens Broadband Radio Service ↗Microsoft Intune — eSIM device configuration ↗Microsoft Intune — what is device management ↗AppDirect — advisor catalog and service categories ↗