Health Monitoring: Unified Governance and Supply-Chain Composite

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 running compliance under UNECE R155 (vehicle cybersecurity), UN R156 (software updates), FDA premarket approval and post-market surveillance, EU Medical Device Regulation, EU NIS2, EU Cyber Resilience Act, or comparable critical-infrastructure mandates 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 UNECE R155 type-approval audit, an FDA post-market 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, multiple authorities sign in a quorum, producing a multi-attester health observation in which a single authority's compromise does not invalidate the composite. The signing structure is identical to the multi-attester pattern used elsewhere in the governance 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, full-quorum, policy-passing health observation receives full operational authority; a device with a stale, partial-quorum, 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 — typically minutes to hours for high-assurance fleets, hours to days 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, the response is computed by the device's PUF circuit (typically an SRAM-based, ring-oscillator-based, or arbiter PUF integrated into the secure element), 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. The verification proceeds in two steps: a measured-boot trace from the device's root of trust attests to the loaded firmware identity at boot, and a runtime measurement attests to the post-boot module set. Both measurements are signed by the device's secure element and compared against a credentialed SBOM signed by the build authority. The SBOM itself carries lineage back through the build pipeline (compatible with SLSA Level 3+, in-toto attestations, and Sigstore signatures), allowing downstream consumers to traverse from the running-device attestation through the build provenance to the source provenance.

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: UNECE R155 cybersecurity reporting (vehicle OEM aggregates across deployed vehicles for type-approval), FDA post-market surveillance (medical device manufacturer aggregates for adverse-event reporting), EU NIS2 incident reporting (critical-infrastructure operator aggregates across operational technology fleets), and insurer underwriting (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

Composite health observation cycles run between 1 minute and 24 hours per device depending on regulatory regime, with the higher rates serving safety-critical applications (automotive UNECE R155 cyber-incident-detection, medical-device-PMA continuous monitoring) and the lower rates serving lower-criticality IoT under general cyber-hygiene mandates. PUF challenge-response runs at a configurable cadence, typically once per credential rotation interval (rotation intervals of 1 to 90 days are common) or on demand from the health authority. SBOM measured-boot attestation runs once per boot; runtime SBOM measurement runs on configurable cadence between 1 minute and 1 hour, with higher cadence on devices supporting continuous integrity measurement.

Credential freshness windows scale with deployment risk: 1 to 15 minutes for high-assurance defense and critical-infrastructure fleets, 15 minutes to 6 hours for regulated-fleet automotive and medical, 6 to 72 hours for general industrial IoT. Revocation propagation tolerance is typically set at 2x to 5x the credential freshness window, with the device entering a degraded operational mode if revocation propagation exceeds the tolerance.

Storage budgets per device for the constituent observation history are dominated by the trust-slope baseline retention. A 30-day rolling baseline at 1-minute granularity occupies on the order of 4 to 16 MB per device depending on the observation feature set; safety-critical applications retain longer histories (90 to 730 days) for forensic reconstruction. Aggregate storage at the fleet operator scales linearly with fleet size and observation cadence; for a fleet of 10^6 devices at 5-minute cadence with 90-day retention, aggregate storage is on the order of 100 TB to 1 PB.

Bandwidth per device for health observation publication is dominated by the SBOM measurement payload and the trust-slope sub-observation. Typical steady-state bandwidth ranges from 1 to 50 kbps per device, with bursts during full-cycle attestation reaching 100 to 500 kbps. The primitive supports differential publication (publishing only changed sub-observations between full cycles) for bandwidth-constrained environments.

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-attester embodiment, two or more independent health authorities sign the composite, each evaluating against its own (possibly overlapping, possibly distinct) policy. Multi-attester signing serves regulated environments where regulator and operator both must attest, and where single-authority compromise must not invalidate the composite. The admissibility rule for multi-attester health observations follows the general multi-attester pattern in the governance chain: a quorum of valid signatures is required, with quorum size set by the consuming policy.

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.

Propagation embodiments include push (device publishes on cycle), pull (consumer requests on demand), gossip (device-to-device propagation through the mesh), and anchored (composite observations periodically anchored to a regulated transparency log such as Certificate Transparency or a domain-specific log). The propagation embodiment is independent of the composite contract; a single device may publish through multiple propagation paths simultaneously 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, secure-element signing, software-attested measured boot).

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 the outputs of those frameworks (SBOMs signed under SLSA, provenance attested under in-toto, signatures verified against Sigstore) as constituent observations and binds them to the running device through PUF challenge-response and measured-boot integration.

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 multi-attester signing topology, 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-attester signing, sub-component selection across heterogeneous device classes, propagation patterns including push, pull, gossip, and anchored), the operating-parameter envelope (cycle cadences, freshness windows, retention budgets, bandwidth profiles), 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.