1. Problem and Architectural Premise

Device health, as practiced in 2026, is the partial output of three vendor categories that do not interoperate at the architectural level. Zero-trust device management products (Microsoft Defender for Endpoint, CrowdStrike Falcon, Armis Centrix, Claroty xDome) authenticate device identity through credential checks, posture assessments, and continuous identity-binding evaluations. The discipline is mature, but the observations these products emit are bound to the product's policy engine and authentication topology. They speak about present-state credential validity, not about whether the silicon under the credential is the silicon that was credentialed at manufacture, and not about whether the firmware running above the silicon corresponds to a credentialed software bill-of-materials.

Supply-chain attestation (Sigstore, in-toto, SLSA, Chainguard, software bill-of-materials tooling produced under CISA and NTIA guidance) traces software components back to their build sources and signs the resulting provenance. The output is tamper-evident with respect to the build pipeline. It is silent, however, on whether the running device actually contains the attested software. A SBOM signed at build time tells a regulator that a particular firmware blob was produced from particular sources by a particular pipeline; it does not tell the regulator that this device, in this configuration, at this moment, is executing that firmware on the silicon it claims.

Trust-slope anomaly detection (User and Entity Behavior Analytics, Endpoint Detection and Response, OT/ICS behavioral monitors) flags departures from a learned device baseline. The observations are statistically grounded and operationally useful, but they are uncoupled from the cryptographic provenance and governance-chain context that authoritative response requires. A behavioral anomaly, by itself, cannot distinguish a benign firmware update from an adversarial substitution; only correlation with credential lineage and supply-chain provenance can.

A regulated-fleet operator in a regulated domain (healthcare, defense, financial services, legal services, critical infrastructure) needs the three views composed into a single auditable assessment. Today the operator integrates them ad hoc, building bespoke pipelines that reconcile vendor outputs, normalize timestamps, and produce a synthesized report that is itself not cryptographically grounded. The architectural premise of this disclosure is that composition belongs at the primitive layer, not at the integration layer, and that the composition produces a credentialed observation rather than a report.

2. Core Architectural Primitive: Composite Credentialed Health Observation

The primitive is a single composite credentialed observation per device per evaluation cycle, signed by a named health authority and bound to a named policy. The observation aggregates three classes of constituent observations into one structurally evaluable artifact: (a) governance-chain credential observations, including current credential authority, credential continuity over the device lifetime, revocation propagation status, and trust-slope behavioral baseline; (b) supply-chain provenance observations, including silicon PUF challenge-response liveness, SBOM verification of running firmware, tamper-evident seal status, and credentialed lineage from manufacture through deployment; and (c) operational context observations, including capability envelope under current policy, mission profile, regulatory framework, and any contextual modifiers (geofence, mission phase, custodianship).

The composite observation is not a score. It is a structurally addressable record in which each constituent observation is reachable by lineage. A consumer who admits the composite admits the named health authority's evaluation under the named policy; a consumer who needs to drill in can traverse to the constituent observations and re-evaluate under a different policy. Policy and evaluation are decoupled from the primitive itself, which is precisely the property that allows the same primitive to serve a regulatory compliance audit, a regulator's surveillance pull, an insurer's underwriting workflow, and an OEM's warranty determination without forking the data model.

The signing health authority is configurable. In a single-operator deployment, the device owner signs. In a regulated deployment, a third-party compliance attester or a regulator signs. In a multi-stakeholder deployment, more than one authority may sign, with the health observation admitted under the same admissibility rules that govern any other observation in the chain, so consumers do not learn a special-case admissibility rule for health.

Health observations propagate through the mesh as governed observations. Peer devices, infrastructure agents, regulators, and insurers consume the observation through composite admissibility, with the health attestation modulating evidential weight, capability admission, and operational authority. A device with a fresh, policy-passing health observation receives full operational authority; a device with a stale or policy-degraded health observation receives correspondingly reduced authority, with the reduction itself being a credentialed observation that downstream consumers can audit.

3. Governance-Chain Integrity Sub-Components

The governance-chain integrity component evaluates four credential-bound properties of the device, each producing its own signed sub-observation referenced by the composite. Credential freshness verifies that the device's current credential is unexpired, unrevoked, and not superseded by a newer issuance. The evaluation respects the issuing authority's freshness window, which is tighter for high-assurance fleets and looser for general-purpose IoT, with the window itself part of the credential, and records the freshness margin so a downstream consumer can assess marginality.

Credential continuity verifies that the device's credential history forms an unbroken trust-slope chain back to its issuance event. Each credential rotation, each authority transition, each capability adjustment is a credentialed observation in the device's lineage. Continuity verification reconstructs the chain and confirms that no segment is missing, no authority transition was unauthorized, and no rotation occurred without supporting evidence of the prior credential's voluntary retirement or revocation. This evaluation is what distinguishes the primitive from snapshot identity verification: a stolen or cloned credential may pass freshness but cannot reproduce a continuity chain whose lineage points back to manufacture.

Revocation propagation evaluates whether the device is responsive to revocation observations the governing authority has issued. A device that is online but has not acknowledged a recent revocation broadcast is structurally suspect; a device that is offline and outside its declared connectivity envelope is in a known degraded state with corresponding policy-defined authority reduction. The evaluation produces a propagation latency observation that consumers can compare against the policy's tolerable revocation lag.

Behavioral consistency applies trust-slope analysis: the device's recent observations are compared against its long-term behavioral baseline, with deviation magnitude and direction recorded. Trust-slope analysis is not anomaly scoring; it is a credentialed comparison against a credentialed baseline, with the baseline itself being a governed artifact whose lineage is auditable. The composite admits the trust-slope sub-observation as one input among several, allowing policies that tolerate behavioral deviation when supply-chain and credential evidence are otherwise strong, and conversely.

4. Supply-Chain Provenance Sub-Components

The supply-chain provenance component evaluates the device's physical and software lineage from manufacture through current operation. Silicon Physical Unclonable Function (PUF) challenge-response provides tamper-evident proof that the device contains the specific silicon credentialed at manufacture. The challenge is issued by the health authority, a physical-unclonable-function challenge-response monitor produces an observation of the device's PUF-response consistency, and the response is verified against a credentialed enrollment record signed by the silicon vendor or contract manufacturer. An attacker substituting hardware fails the PUF challenge because the substituted silicon cannot reproduce the enrolled response, and an attacker cloning the credential without cloning the silicon also fails.

SBOM attestation verifies that the running firmware corresponds to the declared software bill of materials. A firmware integrity chain monitor tracks firmware updates through the authorized-update-authority chain, and a software-bill-of-materials attestation verifier compares the device's firmware identity against a governance-credentialed software bill of materials carried in the device's lineage. The bill of materials is a governed observation with its own signing authority, allowing downstream consumers to traverse from the running-device attestation back through the device's supply-chain lineage.

Tamper-evident seal monitoring, where the device class supports it, provides physical attestation that the device's enclosure has not been opened since credentialing. Seal observations are produced by inspection authorities at credentialed lifecycle events: the manufacturer at packaging, the deployer at installation, periodic auditors during operation, and incident responders during forensic events. Each seal observation carries the inspection authority's credential and the inspection methodology (visual, electrical-continuity, optical-microstructure, or active-tamper-mesh). Seal status is structurally distinct from credential and SBOM status; a device may have a valid credential and verified SBOM yet a broken seal, indicating physical tampering that may have established persistence below the firmware level.

Together, governance-chain integrity (forward-looking, evaluating whether the device is currently and continuously the entity its credential claims) and supply-chain provenance (backward-looking, evaluating whether the device's current state derives consistently from its credentialed origin) cover the full trust history. Either alone is insufficient; the composite is the artifact regulated environments require.

5. Cross-Domain Aggregation and Fleet Composition

Single-device health is the unit of evaluation; regulated fleets need composite health across thousands to millions of devices, with cross-domain aggregation that respects authority boundaries. The aggregation primitive consumes credentialed device-level health observations within an aggregator's scope and produces a credentialed aggregate health observation that summarizes the population under a defined aggregation policy. The aggregator's credential and the aggregation policy are both audit-grade artifacts; a downstream consumer of the aggregate can traverse to the contributing device-level observations through lineage.

Authority scoping is structural. An OEM aggregates over its own deployed devices, regardless of which fleet operator currently runs them, because the OEM credential admits OEM-owned device observations. A fleet operator aggregates over its own operating fleet, regardless of which OEM manufactured them, because the operator credential admits operator-scoped observations. A regulator aggregates over its regulated population, drawing both OEM and operator contributions, because the regulator credential admits both scopes. The same device contributes to multiple aggregates simultaneously without any single aggregator gaining the others' authority.

Aggregation policies define how device-level observations compose. Common policies include population-prevalence summarization (what fraction of the fleet is policy-passing), worst-case bounding (the lowest health observation in the population, useful for regulator pull), capability-weighted aggregation (weighted by device operational criticality), and segmented aggregation (broken down by deployment zone, mission phase, or hardware revision). Each policy produces a structurally distinct aggregate observation; an aggregator may publish multiple policies' outputs simultaneously without producing inconsistency, because the device-level lineage is shared.

Cross-domain aggregation handles the practical regulatory cases directly through the cross-domain parameterization that adapts to a deployment's authority taxonomy: an OEM aggregates across its deployed devices for regulatory reporting, a manufacturer aggregates for adverse-event reporting, a critical-infrastructure operator aggregates across its operational fleets for incident reporting, and an insurer aggregates across an underwriting cohort with policyholder-credentialed contributions. The mechanism is identical; the configurations differ only in scope, policy, and signing authority.

6. Operating Parameters and Engineering Envelope

The primitive produces continuous health observations rather than one-shot checks, and the cadence of each constituent evaluation is governance-policy-defined rather than fixed. Higher-criticality deployments configure more frequent composite cycles and tighter credential freshness windows; lower-criticality deployments configure correspondingly relaxed parameters. The cadence parameters are themselves part of the governing policy, so a downstream consumer reading the composite can see the policy under which it was produced.

PUF challenge-response, firmware integrity chain monitoring, software-bill-of-materials attestation, and trust-slope baseline comparison each run on a policy-defined schedule or on demand from the health authority. Credential freshness windows scale with deployment risk, with high-assurance fleets configuring tighter windows and general-purpose fleets configuring looser ones; revocation propagation tolerance is likewise a policy parameter, with the device entering a policy-defined degraded operational mode when propagation exceeds the configured tolerance.

The constituent observation history is carried in the device's lineage and retained under the governing retention policy, with safety-critical applications retaining longer histories for forensic reconstruction. Aggregate storage and bandwidth at the fleet operator scale with fleet size, observation cadence, and retention policy. The primitive's operating envelope is defined by the governing policy in each deployment rather than by a fixed schedule.

7. Alternative Embodiments

The primitive admits a range of embodiments differing in signing topology, sub-component selection, and propagation pattern, all preserving the composite credentialed observation contract. In a single-authority embodiment, the device owner signs the composite directly, with the constituent observations bound by the owner's credential. This embodiment serves enterprise IT environments where the owner is also the regulatory subject and no third-party attestation is required.

In a multi-stakeholder embodiment, two or more independent health authorities sign the composite, each evaluating against its own (possibly overlapping, possibly distinct) policy. This serves regulated environments where regulator and operator both must attest. The admissibility rule for these health observations is the same one the governance chain applies to any multiply-signed observation; the consuming policy decides how many of the signatures it requires.

Sub-component selection varies with device class. Devices without a PUF (legacy IoT, software-only endpoints) substitute a credentialed software identity binding; devices without a tamper-evident enclosure (consumer-grade endpoints) omit seal monitoring; devices without behavioral baseline support (single-purpose embedded controllers) omit trust-slope analysis. The composite remains structurally identical with the missing constituents recorded as not-applicable rather than failing, allowing aggregation across heterogeneous fleets without false-negative inflation.

Health observations are distributed through the governed mesh as governed observations, routed by the same mechanism that carries any other observation in the chain. Distribution is independent of the composite contract; a device may publish a composite observation on cycle or in response to a consumer request without producing inconsistency.

8. Composition with Broader Architecture

The health monitoring primitive is one of five composing properties in the broader governance chain. It composes upward with capability admission (composite health modulates the capability envelope a device may exercise), with mission policy (mission phases may demand higher health thresholds), with cross-mesh reconciliation (a device crossing administrative boundaries carries its composite health observation), and with confidence-governed actuation (the actuation primitive consumes composite health as an input to its admissibility evaluation).

Downward, the primitive composes with the constituent governed observations: device credentials produced by the credential-issuance primitive, SBOM attestations produced by the build-pipeline primitive, PUF enrollment records produced by the manufacturing primitive, and trust-slope baselines produced by the behavioral-baseline primitive. Each constituent has its own lineage, its own signing authority, and its own admissibility rules; the composite is the structurally minimal artifact that admits all of them simultaneously under one health authority's evaluation.

Lateral composition with adjacent primitives is direct. Mesh-distributed firmware updates consume composite health as a precondition (only devices passing the policy receive an update; devices failing receive a triage observation instead). Confidence-governed actuation consumes composite health as a weight on the admissibility evaluation. Marker-track transport and matched-pair settlement consume composite health for the participating devices in a transaction. Across these compositions, the health observation is admitted on equal structural footing with any other governed observation, which is the property that makes the broader architecture coherent rather than a collection of point integrations.

Integration with installed-base zero-trust device management, SIEM, EDR, and SOC tooling is policy-level. Microsoft Defender, CrowdStrike, Armis, and similar products consume the composite health observation as a structured input to their existing policy engines; the integration does not require replacing those products. This is decisive for adoption, because regulated-fleet operators have made significant investment in the existing stack and are not in a position to replace it. The governed primitive provides the unified observation those products structurally lack; the products consume it without architectural disruption.

9. Prior-Art Distinctions

The primitive is structurally distinct from TPM-only attestation. A Trusted Platform Module produces a measured-boot quote signed by an Endorsement Key. The TPM quote is one constituent observation that the composite may consume; the composite is not a TPM quote, does not depend on TPM presence, and does not terminate at the TPM trust boundary. A TPM-attested device with a valid quote may still fail the composite if its credential continuity, revocation propagation, or supply-chain provenance fails. A device without a TPM may still pass the composite if it provides equivalent constituent observations through alternative means (PUF challenge-response, firmware integrity chain monitoring, software-bill-of-materials attestation).

The primitive is structurally distinct from device-management platforms (Microsoft Defender, CrowdStrike, Armis, Claroty, Microsoft Intune, VMware Workspace ONE). Those platforms are policy engines that consume vendor-defined posture observations and emit allow/deny decisions within their own authority topology. The composite is a credentialed observation independent of any single vendor's policy engine, signed by a named health authority that may or may not be the device-management platform. The platforms consume the composite; they do not produce it.

The primitive is structurally distinct from supply-chain risk management policy frameworks (NIST SP 800-161, SLSA, in-toto, Sigstore, CISA SBOM guidance). Those frameworks define how supply-chain provenance is produced and what properties it should have; they do not specify a runtime composite observation that combines provenance with credential lineage and trust-slope behavior. The composite consumes governance-credentialed software-bill-of-materials and provenance observations as constituent observations and binds them to the running device through PUF challenge-response and firmware integrity chain monitoring.

The primitive is structurally distinct from UEBA and EDR products. Those products produce behavioral-anomaly observations without cryptographic provenance; the composite admits trust-slope analysis as a constituent observation with explicit credentialing and lineage, and combines it with credential and provenance evidence that anomaly products structurally do not produce. The composite supports authoritative response in a way that anomaly-only architectures cannot.

10. Disclosure Scope

Disclosed under USPTO provisional application 64/049,409, the health monitoring primitive covers the composite credentialed observation contract, the constituent sub-component evaluation set (governance-chain integrity, supply-chain provenance, operational context), the configurable health-authority signing including single-authority and multi-stakeholder signing, the cross-domain aggregation primitive with authority-scoped policies, and the composition with adjacent primitives in the governance chain (capability admission, mission policy, cross-mesh reconciliation, confidence-governed actuation, mesh-distributed firmware updates, marker-track transport, matched-pair settlement).

Disclosure includes the alternative embodiments described above (single-authority and multi-stakeholder signing, sub-component selection across heterogeneous device classes, and distribution of health observations through the governed mesh), the policy-defined operating envelope, and the integration interface with installed-base zero-trust, SIEM, EDR, and SOC tooling.

The primitive composes with the broader governance-chain umbrella disclosed in the same provisional, including mesh-derived coordinates, mesh-derived time, marker-track transport, matched-pair settlement, capability admission, mission policy, and cross-mesh reconciliation. The composition is by structural admissibility of governed observations and does not introduce new admissibility rules specific to health.