The SCG Responsibility Model

Introduction

In this series, we established A³RA as the test for trustworthy action and introduced the Security, Compliance, and Governance (SCG) Framework as an architectural model for passing that test at scale, with minimal cost and complexity.

The SCG Framework assumes that Compliance is the most commercially valuable capability to automate—and therefore the practical objective of the design.

A compliance objective may include:

• Granting market access and avoiding fines (for example: EU Cyber Resilience Act, data residency requirements, the EU Data Act).
• Achieving industry certification (for example: a target security level within IEC/ISA 62443-4-2).
• Satisfying internal policy requirements (for example: a minimum security posture required by corporate policy, or a product differentiation requirement).

In this model, connected product Security is not an end in itself, but the essential foundation in service of compliance objectives. Governance updates policy, prioritizes remediation, and ensures accountability—also in service of compliance objectives.

Compliance itself is a comparative function: it evaluates the Security Posture of connected products against regulations, standards, and policy obligations. Because multiple compliance objectives will exist simultaneously, the SCG Framework is designed to scale in complexity over time.

Critically, compliance objectives are enforced across the two logical planes where cyber-physical actions take place:

• The Data Plane defines interfaces and policy for telemetry, analytics, and diagnostics.
• The Control Plane defines interfaces for firmware updates, configuration changes, and actuation commands.

The SCG Framework is also designed so that the center of gravity for each letter in the acronym maps to natural physical or logical abstractions in connected service design: the Edge (Security), the Operational Cloud (Compliance), and the Policy Cloud (Governance).

In practice these responsibilities are not mutually exclusive, but the division of labor serves as a useful mental model. Collectively, SCG makes the principles of A³RA—admissible, attributable, auditable, and recoverable action—a commercially viable, technically enforceable reality.

Layer 1: Security at the Edge — “The Actor”

The device/edge layer is where actions physically occur. This is the Actor in the model, operating in the real world. For this layer to be both safe and effective, it must be an empowered and responsible agent.

Primary role: Local admissibility & attributable action

• Enforces local admissibility: the edge enforces admissibility locally by acting on rules provided by the cloud. It continuously checks its own actions against those rules to ensure it is operating acceptably.
• Guarantees foundational safety: it enforces hardcoded, non-negotiable safety constraints (for example: “never exceed a physical limit”) that cannot be overridden by remote command.
• Acts with verifiable integrity: it uses secure, cryptographic identity to make actions and reports attributable, proving the device is the authentic source.

Implementation design

In the SCG Framework, the Edge is principally responsible for the Security of the device.

Security is the verifiable, machine-observable description of a connected product’s actual state at a point in time. It consists of immutable or slow-changing properties, dynamic states, and local policy that collectively express integrity, identity, and operational condition. This is captured as the device’s Security Posture.

The Security Posture may be managed directly on the device, or managed on behalf of the device by a gateway, depending on topology and whether the architecture is retrofitting brownfield devices or implementing a greenfield design.

Security in SCG is descriptive, not evaluative. It answers: “What is this device, and what state is it in right now?”

Security does not determine whether a state is acceptable, legal, or permitted—that responsibility belongs to Compliance. Instead, Security provides the ground truth on which all compliance decisions and governance actions depend.

Typical security properties include firmware identity, cryptographic credentials, configuration state, execution mode, and attested measurements originating from the device or its trusted runtime.

Layer 2: Compliance in the Operational Cloud — “The Arbiter”

The Operational Cloud serves as the compliance engine for a fleet of connected products. This is the Arbiter: it compares each device’s Security Posture against a contextual definition of compliance. It inherits policy definitions and access rights from the Policy Cloud and re-hydrates context needed to evaluate whether posture is within an acceptable range for one or more compliance objectives.

Primary role: Defining admissibility & observing compliance

• Defines and distributes rules of admissibility: the Arbiter translates high-level goals from Governance into concrete operational rules and securely provides them to edge devices.
• Compares current posture to compliant ranges: it monitors the fleet to detect drift outside permitted boundaries, without becoming a transactional bottleneck for every action.
• Arbitrates fleet-level decisions: it handles admissibility questions that require a cross-asset view no single device possesses (for example: coordinating actions between assets).

Implementation design

Rather than enforcing a single static configuration (which often breaks industrial operations), the compliance engine evaluates whether a device’s current posture falls within a permitted set of values:

Compliance(Device) = for all properties P in Posture(Device):
                     Value(P) ∈ AcceptableRange(P)

For each property in the Security Posture, define an acceptable range that can be dynamic and contextual:

AcceptableRange(P) may include:
- allowed_values:   e.g., permitted firmware versions
- allowed_min/max:  e.g., certificate age windows, patch-level dates, utilization thresholds
- context_rules:    e.g., site/operator constraints, maintenance mode exceptions, safe-mode status

This model is intrinsically dynamic. It allows multiple valid firmware versions, varying certificate expiry windows, and exception states (for example: maintenance mode) to exist simultaneously in a compliant fleet. That flexibility enables automation at fleet scale while accommodating the messy reality of operations.

The Arbiter’s job is to ensure the right rules are in the right hands—and to be the first to know when those rules are not being followed.

Layer 3: Governance in the Policy Cloud — “The Authority”

Governance is where human intent meets the system. It is where leaders define mission objectives and where ultimate accountability resides. It defines who is authorized to change posture, what happens when compliance fails, and how remediation is prioritized. This is the Authority.

Primary role: Setting intent & owning accountability

• Authoritative source of intent: business, operational, safety, and legal policies originate here.
• Manages digital rights: governs who can define policy, who can operate the system, and who can intervene in emergencies (for both humans and devices).
• Anchors auditability: holds the rationale and history behind the rules enforced across the fleet.

Implementation design

The Policy Cloud owns global governance logic and policy enforcement. It pushes policies southbound to the Operational Cloud, defining:

• Constraints (for example: minimum firmware versions)
• Requirements (for example: mandatory network isolation patterns)
• Configuration (for example: data manifest rules and application-specific requirements)

Industrial assets—especially mobile ones—often operate in denied environments where connectivity is intermittent. For this reason, SCG relies on cached governance at the Edge.

• Persistence of policies: the device enforces the last known good policies even when offline. It cannot revert to an insecure state simply because the cloud is unreachable.
• Audit caching: governance events are logged locally for future audit (for example: local logins, blocked actions) and queued for upload when connectivity returns. A posture “bookmark” can indicate the last successfully synchronized audit position so the cloud can recover missing events and preserve chain of custody.

Defining clear scopes of authority

A key function of Governance is recognizing that authority is not one-size-fits-all. The framework accounts for this by defining clear scopes of authority so the right people have the right level of control.

Authority can be geographic: a fleet manager for Europe has authority over European assets but cannot change rules for devices in North America.

Authority can be role-based: a support technician may be authorized to view diagnostics but not to issue firmware updates. That power is reserved for qualified roles.

This enforces least privilege at the highest level of the system and creates a clear audit trail showing not just what policy changed, but who had correctly scoped authority to change it.

The Governance layer is where authority originates—and where the buck stops.

Why this separation matters

Resilience and safety by design

Because the edge has its own understanding of admissibility, it can continue operating safely—even if it loses connection to the cloud. This is foundational to resilient systems.

Agility and scalability

The cloud is freed from being a transactional bottleneck. By focusing on defining rules and observing exceptions, it can manage a fleet of millions as effectively as a fleet of one hundred. When regulations change, the Arbiter distributes new rules—without requiring firmware updates or fleet-wide downtime.

Auditability without ambiguity

This architecture provides a clear, defensible audit trail. When an incident occurs, the questions are simple and the answers are clear:

• Who defined the policy intent? (The Authority.)
• What rules of admissibility were sent to the device? (The Arbiter.)
• Did the device enforce those rules? (The Actor.)

This transforms A³RA from a concept into an implementable and defensible architecture.

Conclusion

The SCG Framework is more than a technical architecture; it is a model for operationalizing trust.

By defining responsibilities across Security (the Actor), Compliance (the Arbiter), and Governance (the Authority), it provides a clear path to achieving and maintaining a trustworthy posture for connected products at scale. It turns the abstract principles of A³RA into a commercially viable and technically enforceable reality.

It recognizes that the edge must be an empowered, responsible agent—not a dumb endpoint. It treats compliance as dynamic, not a checkbox. And it addresses disconnected operations through resilient cached governance.

This is how organizations move beyond treating security and compliance as a tax and begin to leverage them as a competitive advantage—unlocking market access, building customer confidence, and enabling innovation with a foundation of verifiable trust.

Now that the architecture and its core responsibilities are defined, we can turn to the data that brings it to life.

Next: the essential pillars of a device’s Security Posture—what a device must provide to prove its own trustworthiness and enable the compliance, governance, and remediation cycle this framework makes possible.