The Security Posture Model
Trust Anchor, B-R-E Evidence, and the Manifest
In the previous Foundation, we defined the three layers of the SCG Framework: the Actor, the Arbiter, and the Authority. That system depends on a continuous flow of data from the edge device.
To make trustworthy decisions, systems cannot rely on an arbitrary collection of metrics. They require a formal data model that describes device state in a structured, verifiable way. In the SCG Framework, this model is called the Security Posture Model.
The Security Posture Model is not a flat list of attributes. It is a hierarchy of dependencies built on a foundation of trust. It consists of three tightly coupled components:
- The Trust Anchor (Identity)
- Security Posture Evidence (B-R-E)
- The Manifest (Local Authority Scope)
1. The Foundation: The Trust Anchor (Identity)
Role: The prerequisite for belief.
Before we can believe what a device reports, we must first trust who is speaking. The Trust Anchor is the device’s foundational cryptographic identity. It is not posture data itself; it is the root of trust that makes posture data believable.
Its sole purpose is to provide a secure origin for cryptographic proof.
Key question it answers: “Can this device prove it is who it claims to be?”
The strength of the Trust Anchor directly determines how much trust can be placed in the device’s data — and what level of authority can safely be delegated to it. Choosing an anchor is therefore a fundamental risk management decision.
Hardware-backed (e.g. TPM)
This is the highest-assurance tier. A hardware-backed identity enables trusted boot, secure key storage, and strong attestation, making it possible to automate high-impact Control Plane actions such as firmware updates.
Software-backed (e.g. software agent)
A key protected by the operating system provides moderate assurance. Data streams may be trusted under normal conditions, but high-risk actions may require additional verification or human approval.
Declarative (e.g. MAC address)
This provides the lowest assurance and is suitable only for low-risk Data Plane monitoring. Without cryptographic identity, data is not truly attributable, and Control Plane authority should be disabled by default.
2. The Evidence: Security Posture Evidence (B-R-E)
Role: The set of verifiable facts.
Once identity is established, the device must present evidence. This evidence is the Security Posture itself: the descriptive facts about the device’s build, its current internal state, and its external operating environment.
Key question it answers: “What is the device’s state and its operational situation right now?”
This evidence model is not one-size-fits-all. Its scope expands or contracts based on compliance objectives (e.g. EU CRA), assurance level (e.g. IEC 62443), and system autonomy. The posture evidence is grouped into three categories:
(B)uild-time properties
The device’s “golden baseline” properties — static or slow-changing relative to operation. Examples include hardware model, firmware identity, and SBOM.
(R)un-time properties
The device’s live internal state: execution mode, memory usage, active connections, and enforced policy configuration. These properties help detect drift, compromise, or unsafe operating modes.
(E)nvironment properties
The device’s observed external context, such as network segment, physical location, or connected peripherals. These contextual signals influence admissibility and safety decisions.
While described here for a single device, the model naturally extends to composite systems where a controller aggregates and evaluates the postures of subordinate components.
3. The Rules: The Manifest
Role: The embodiment of the device’s Explicit Authority Scope.
Evidence alone is descriptive; it does not grant authority to act. Authority must be explicitly delegated.
This delegation is expressed through the Manifest — the local, signed representation of the device’s Explicit Authority Scope. The Manifest defines what the device is permitted to do, under what conditions, and how it must respond when conditions are not met.
It is provisioned by the Governance layer and enforced locally by the device.
Key questions it answers:
- Is this proposed action within my Explicit Authority Scope?
- Is it admissible right now?
- If not, what remediation is authorized?
Local vs. cloud evaluation
The Manifest enables a local control loop, distinct from full cloud-based compliance evaluation.
Local Decisions & Remediation (Within Scope)
The device autonomously enforces policy within its delegated authority and records all actions in its local journal.
- Control Plane: “I am connected to an unauthorized Wi-Fi network. My scope authorizes me to disable the interface and log the action.”
- Data Plane: “This record contains PII requiring redaction. I am authorized to redact locally before transmission.”
Comprehensive Cloud Evaluation (Outside Scope)
Actions requiring broader context or higher authority are escalated to the Arbiter.
- Control Plane: “My firmware is out of date. I lack authority to update myself. I will report this state for remediation.”
- Data Plane: “I am asked to transmit a data type not defined in my Manifest. This exceeds my Authority Scope. Transmission is blocked pending policy update.”
Conclusion: A Resilient and Auditable Model
The Security Posture Model — composed of a Trust Anchor, B-R-E evidence, and a Manifest — creates a verifiable chain of trust from identity to action.
It enables attribution, distributed admissibility, and recoverability through a two-stage process:
- Locally: the device enforces policy, performs remediation within scope, and journals actions.
- In the cloud: journals synchronize on reconnection, posture is evaluated against full policy, and governance actions are taken.
This model is the engine that powers the SCG Framework, enabling scalable, automated, and accountable governance — from local recovery to fleet-wide compliance.