Device Terrain Identification

Control Statement

Every device with a path into the estate shall be represented on the terrain overlay with its management state, its owning population, and the terrain it can reach.

Purpose. To make devices positional, so that the crossings into the estate are known and can be defended rather than merely counted.

Discussion

The distinguishing requirement is **management state**, and the category that matters is the one most inventories omit: devices that reach the estate and are not managed by it. Contractor laptops, personal devices under a bring-your-own arrangement, vendor maintenance endpoints and unenrolled cloud workstations all cross the ford, and an inventory built from the management console will report none of them because the console can only see what it manages. Reconciling against the identity plane rather than the endpoint platform is what surfaces them.

Goals and Metrics

A metric that cannot come out badly is not a metric. Each of these is capable of reporting that the control is not working.

Accountability

Exactly one role is accountable, and every other role carries at least Informed — no control in the published catalog leaves a role with zero relationship to it. That is a stated property of how these were authored, not a coincidence, and not a claim that every role's work is worth equal attention here.

Inputs and Outputs

Activities

1. L2Represent devices with a path into the estate on the terrain overlay.
2. L2Record the management state of each — managed, unmanaged, or unknown.
3. L2Record the population that operates each device class.
4. L3Reconcile the device set against the identity plane (ID-1) rather than against the endpoint management console, since the console can only report devices it already manages.
5. L3Record the terrain each device class can reach, so a device is scored by its reach rather than by its cost.
6. L3Classify unmanaged devices as a measured population with an owner and a disposition, not as an exception to the inventory.
7. L3Record the software inventory carried by each managed device class, so a component disclosure can be resolved to devices rather than to an estate.
8. L4Trend the unmanaged population against the managed one, and set a threshold above which the estate is not fit to plan device defense from.
9. L4Measure the interval between a device first authenticating and its appearance on the overlay.
10. L5Remove the conditions that generate unmanaged reach — brokered access, virtual desktops, or enrollment requirements — rather than counting it indefinitely.

Measurement

Evidence and Assessment

Related Guidance

Position in the Chain

Derived from the other controls’ own declarations, so the two directions cannot disagree.

Where This Control Is Used

Derived, in every case, from the declaration at the other end: the forms whose techniques name this control, the artifacts whose producing and consuming controls include it, the layers whose control lists name it, and the roles its own accountability chart puts to work. Nothing here is authored on this page, so the sheet cannot claim an edge the other end does not.