Asset identification, management and attestation

Why this matters

Lesson five covered asset management as governance — the life cycle, the CMDB, and reconciliation. This objective asks a harder architectural question about the same subject: on what basis do you believe an asset is what it claims to be?

That question has become load-bearing because every control in the next few lessons depends on the answer. Device posture as an input to an access decision is worthless if the device can lie about its posture. Zero trust evaluates the subject and the object, and both must be identifiable. A data perimeter admits identified assets and excludes others.

The architectural answer is attestation: a claim about a system's state that is backed by something the system cannot forge, because it is rooted in hardware the software cannot modify. CAS-005 tests whether you know the difference between a system reporting its state and a system attesting to it, and whether you can identify the assets in a modern estate that have no hardware at all.

The lesson

Identifying an asset that has no hardware: a role, a key, a hosted zone, a pipeline

The assets that cause incidents in a cloud-era estate are frequently not machines, and inventory practices inherited from a hardware world do not see them.

Categories worth enumerating explicitly, because each has caused real breaches:

• Identities. Users, groups, service accounts, roles, workload identities. Each grants access, each has a lifecycle, and each should have an owner. In many estates this is the largest asset class by count and the least managed.
• Credentials. API keys, tokens, certificates, signing keys. They expire, they are copied, and they are frequently the thing actually compromised.
• DNS zones and records. A hostname is an asset with reputation and trust attached, and lesson five's subdomain takeover is what happens when nobody owns it.
• Cloud accounts and subscriptions, which are containers whose existence outside the organisation structure makes everything inside them invisible.
• Pipelines and their definitions, which can deploy to production.
• Container images and their registries.
• SaaS tenancies, including the shadow ones from lesson thirteen.
• Data sets, as distinct from the systems holding them — the analytics extract that lesson seven described belongs to something.
• Third-party integrations and consent grants.

Two properties make these harder than hardware. They are created in seconds, usually by automation, so the rate of creation exceeds any manual registration process. And they are created by many people through many routes — console, API, pipeline, a third-party tool — so a single registration chokepoint does not exist.

The consequence is architectural: inventory must be derived from the platform, not maintained alongside it. Enumerate identities, keys, zones and accounts from the systems of record by API, continuously, and treat the record as a projection rather than as a source. That is the opposite of how hardware inventory worked, and carrying the old model across is the failure a scenario describing an unknown service account is pointing at.

Attestation: hardware roots of trust, measured boot and remote attestation

Attestation answers the question the lesson opened with, and it works by anchoring a claim in something the software being measured cannot alter.

Root of trust. A component trusted by assumption because it cannot be modified — immutable boot code, a trusted platform module, a secure element. Everything above it is trusted only insofar as it is measured by something below.

Measured boot. Each stage of boot measures the next — computes a hash of it — and extends that measurement into a protected register before handing over control. The registers can be extended but not reset or set arbitrarily, so the resulting values are a fingerprint of exactly what was loaded, in order. Crucially, this records rather than enforces: measured boot does not stop a modified component loading, it makes the modification evident afterwards.

That distinguishes it from secure boot, which verifies signatures and refuses to load unsigned components. The two are complementary and the distinction is examinable: secure boot prevents, measured boot evidences.

Remote attestation is what makes the measurements useful to something other than the machine itself. The device sends its measurements, signed by a key held in the hardware root of trust and bound to that device, to a verifier. The verifier checks the signature — establishing which device — and compares the measurements against known-good values — establishing what state it booted in. Only then is access granted.

The property that matters: the signing key never leaves the hardware, so a compromised operating system cannot forge an attestation for a state it is not in. It can refuse to attest; it cannot attest falsely.

Confidential computing extends the same idea to running workloads, where a hardware-protected enclave attests to the code executing inside it. This gives a remote party grounds to believe a specific workload is running unmodified on hardware they do not control — which is the strongest available answer to "prove the provider cannot tamper with this", and it returns in domain 3.

Device posture as an input to an access decision rather than a one-time enrolment

Enrolment establishes that a device was registered once. Posture asks what its state is now, and the architectural move CAS-005 tests is treating posture as a continuous input to authorisation rather than as a gate at the door.

Posture signals, roughly in order of how forgeable they are:

• Hardware attestation of boot state — the strongest, for the reasons above.
• Disk encryption enabled, verified through the platform.
• Endpoint protection present, running and current.
• Operating system patch level and configuration compliance.
• Device management enrolment and compliance status.
• Self-reported software agent claims — weakest, because a compromised device reports what its attacker chooses.

That ordering is the lesson. A posture check built entirely on an agent's self-report is a check that fails exactly when it matters, because the scenario it exists for is a compromised device. Anchoring at least the identity of the device in hardware is what makes the rest meaningful.

Continuous evaluation is the second half. Posture changes during a session: protection is disabled, a policy lapses, a device leaves management. A decision made at connection and never revisited is stale within hours, which is precisely the always-on VPN limitation from the previous lesson. The architecture that addresses it re-evaluates on a schedule and on signal, and can downgrade an existing session — restrict, require re-authentication, or terminate — rather than only refusing a new one.

Graduated response is what makes this usable. Binary allow/deny produces either lockouts or exceptions; a graduated model grants full access to a compliant device, restricted access to a partially compliant one, and remediation-only access to a failing one. Users keep working, and the incentive to remediate is immediate.

Managing assets you do not own: contractor laptops, supplier-hosted services, embedded devices

Three categories where the standard controls do not apply, and each needs a different answer.

Unmanaged and contractor devices. You cannot enrol them, mandate their configuration or inspect them, and often cannot lawfully. Three workable patterns: brokered access, where work happens in a virtual desktop or browser-isolated session so data never lands on the device; agentless posture signals — a certificate, a browser-based check, a network-level assessment — which are weaker but not nothing; and data-centric control, where protection travels with the data rather than depending on the device. The wrong answer, and a common scenario, is treating an unmanaged device as managed because it passed a check it was trusted to perform on itself.

Supplier-hosted services. You own the data and not the infrastructure, so assurance is contractual and evidential rather than technical — lesson eight's questionnaires, attestations and right-to-audit clauses. Architecturally, what you can still control is your side: the identity used to access it, what data is permitted to reach it, the integration's scope, and the logs you ingest from it. The service is an asset in your inventory with an owner, even though the servers are not yours.

Embedded, operational technology and IoT devices. Frequently unpatchable, frequently running unsupported software, and frequently unable to host any agent — with lifetimes measured in decades rather than years. The architectural answer is compensating isolation: a dedicated segment with enumerated flows, monitoring of that segment's traffic as the detection mechanism since the device cannot report anything, and a documented exception with an owner in the register from lesson one. Attempting to bring them up to the general standard is the answer scenarios offer and reject, because it is not achievable and pretending it is prevents the isolation that would actually work.

Tying asset identity to the CMDB from domain 1 so both stay true

The closing synthesis, and it is the practical connection between the two objectives that share this subject.

The CMDB from lesson five is the organisational record: ownership, classification, business service, lifecycle, relationships — facts a machine cannot determine about itself. Attestation and platform enumeration give technical identity and state — facts a spreadsheet cannot know. Each is incomplete and each corrects the other.

The integration worth building:

• The record is keyed on an identity the platform can assert, not on a hostname or an IP address. A hardware-rooted device identifier, a workload identity, a resource identifier — something stable and unforgeable.
• Technical attributes are derived continuously from the platform; organisational attributes are maintained by people. Trying to maintain technical state by hand guarantees it is wrong; trying to derive ownership automatically guarantees it is meaningless.
• Reconciliation runs continuously and produces the three classes from lesson five — observed-not-recorded, recorded-not-observed, and attributes disagreeing — each an owned finding.
• Access decisions read the joined view. The access control asks the platform who the device is, the record what it is for and who owns it, and the posture system what state it is in. A decision using only one of the three is making a judgement on a third of the information.

The reason this matters beyond tidiness: an asset that cannot be identified cannot be authorised, monitored meaningfully, or included in a scope — and every downstream control degrades in the same silent direction that lesson five described. Attestation is what makes identity something you can rely on rather than something you assume, and the CMDB is what makes identity mean something to the organisation. Neither is sufficient alone, and scenarios describing an incident involving "a device that should not have been on the network" usually have both halves missing.