Field note / endpoint management

Enrolled and visible beats owned and unknown.

Endpoint work becomes a recurring lane when devices are enrolled, reachable, and governed by a known pattern - not because your firm can name every laptop a client has ever purchased.

Device state

Enrolled and managed

The device sits in an agreed management platform with visible status, policy, and inventory.

Included pattern: Routine patching follow-up, configuration drift checks, agreed application updates, and asset inventory.
Required inputs: Management platform access, enrollment confirmation, and the approved configuration baseline.
Explicit exclusions: Hardware repair, warranty claims, and procurement decisions.

Device state

Requested but unmanaged

A client asks for coverage on a device that has not yet been enrolled or inventoried.

Included pattern: A defined enrollment step becomes the first action, not an assumption that coverage already exists.
Required inputs: Ownership confirmation, an enrollment window, and user cooperation for setup.
Explicit exclusions: Retroactive coverage claims for the period before enrollment completes.

Device state

Legacy, personal, or BYOD

The device sits outside the supported pattern - an old operating system, a personal machine, or an unmanaged brand.

Included pattern: A documented exception note and, where appropriate, a remediation or replacement recommendation.
Required inputs: An honest description of the gap and who owns the decision to remediate or exclude it.
Explicit exclusions: Silent best-effort support that is never written into the service boundary.

Device state

End of life or end of support

The hardware or operating system has reached a point where the supported pattern no longer applies.

Included pattern: Flagging the device in the recurring review with a replacement or exception recommendation.
Required inputs: An inventory that actually tracks age and support status, not a guess.
Explicit exclusions: A promise that unsupported hardware behaves like supported hardware.

Boundary table

Four questions that belong to qualification, not the public offer.

Question	Why the public bands cannot answer it	Where it gets answered
How often are patches applied?	Cadence depends on the management platform, the client's change tolerance, and the agreed maintenance window.	Written into the service boundary record.
Which operating systems are supported?	Supported versions change over time and vary by device fleet.	Confirmed during environment qualification.
What happens to a lost or stolen device?	Response depends on encryption status, remote-wipe capability, and who holds that authority.	Named in the access and authority plan.
Who buys the replacement?	Procurement and hardware ownership are commercial decisions, not fulfilment ones.	Stays with the partner unless the agreement says otherwise.

See the full procurement and licensing boundary →

Representative pattern

Most recurring lanes start narrower than the fleet.

Start with the devices already enrolled in a known management platform.
Add a defined enrollment step for devices your client wants covered next.
Name the exception path for anything legacy, personal, or end of life.
Review the inventory on a cadence so drift does not become invisible.

This is a process description, not a claim about a specific fleet size, platform, or current client base.

Endpoint data protection is scoped as its own lane →

Device monitoring beyond patch cadence is scoped as its own lane →

Related decision

Endpoint access still needs a purpose and an end.

Remote management access should follow the same lifecycle as every other credential: purpose, authorization, least privilege, and revocation.

Review tooling and access

Bring a device pattern - not a hardware inventory.

A high-level count of managed, unmanaged, and legacy devices is enough for an initial fit review.

Discuss an endpoint lane