RCAN v2.1 is Here:
Firmware Attestation, EU AI Act Compliance, and Fleet Orchestration

Today we're shipping RCAN v2.1 — the first major version of the Robot Communication and Autonomy Network protocol — alongside rcan-py 1.1.0, rcan-ts 1.1.0, OpenCastor v2026.3.26.1, and the RRF v2.1 API backend. This is a clean break from v1.x, with no version negotiation and no backward compat. Here's what changed, why it matters, and what you need to do.

---

What's in RCAN v2.1

1. Signed Firmware Manifests (§11)

Every RCAN v2.1 robot must be able to prove what software is running on it. The firmware manifest is a signed JSON document listing every installed component and its SHA-256 hash. It's published at /.well-known/rcan-firmware-manifest.json and its hash travels in every message envelope as field 13 (firmware_hash).

castor attest generate   # scans installed packages
castor attest sign --key robot-private.pem
castor attest verify --key robot-public.pem

This isn't just cryptographic ceremony. It answers the question: is this robot running what it claims to be running? When a fleet orchestrator commands 50 robots, it can verify each one before the first packet is sent.

2. CycloneDX SBOM + RRF Countersigning (§12)

The Software Bill of Materials tells you where every dependency came from. We generate CycloneDX v1.5 SBOMs with RCAN extensions (x-rcan.rrn, x-rcan.spec_version) and push them to the Robot Registry Foundation for countersigning. The RRF countersig is the chain-of-custody receipt.

castor sbom generate
castor sbom publish --token <rrf-token>

The SBOM lives at /.well-known/rcan-sbom.json and the URL travels in envelope field 14 (attestation_ref). Any party — regulators, partners, auditors — can independently verify the supply chain at any time.

3. M2M_TRUSTED Fleet Orchestration (§2.9)

Multi-robot scenarios need a way for an orchestrator to command multiple robots simultaneously. The old approach — giving the orchestrator a CREATOR-level token for each robot — doesn't scale and has no revocation path.

M2M_TRUSTED (role level 6) solves this: the Robot Registry Foundation issues short-lived JWTs that name an explicit fleet_rrns list. Each token requires multi-owner consent — every robot's CREATOR must agree before a token is issued. Any CREATOR can revoke at any time. Robots poll the RRF revocation list every ≤ 60 seconds; revoked sessions are terminated within that window.

// M2M_TRUSTED JWT claims
{
  "sub":         "orchestrator:my-fleet-brain",
  "iss":         "rrf.rcan.dev",
  "rcan_role":   "m2m_trusted",
  "rcan_scopes": ["fleet.trusted"],
  "fleet_rrns":  ["RRN-000000000001", "RRN-000000000005"],
  "exp":         86400,
  "rrf_sig":     "<Ed25519 base64url>"
}

4. Authority Access — EU AI Act Art. 16(j) (§13)

The EU AI Act requires high-risk AI systems to cooperate with national competent authorities on demand. RCAN v2.1 implements this at the protocol level with two new message types: AUTHORITY_ACCESS (41) and AUTHORITY_RESPONSE (42).

When an authority sends an AUTHORITY_ACCESS request, the robot immediately notifies the owner (regardless of validity), logs the interaction to the commitment chain, validates the authority's RRF-registered token, and responds with the requested audit data — commitment chain, transparency records, SBOM URL, firmware manifest URL. The entire flow is verifiable and auditable after the fact.

The EU AI Act's August 2, 2026 deadline for high-risk AI systems means this isn't optional. Robots running OpenCastor v2026.3.26.1 satisfy the protocol-level requirements now.

5. L5 Conformance — Supply Chain (§L5)

RCAN now has five conformance levels. L5 is new:

• L1 — Basic RCAN messaging
• L2 — Signed RURI, RBAC, replay protection
• L3 — ESTOP QoS2, federation, multi-modal
• L4 — Commitment chain, transparency, HiTL
• L5 (new) — Firmware attestation, SBOM, authority access, 10yr audit retention

castor doctor        # includes L5 checks
castor conformance   # structured JSON with EU AI Act article mapping

6. Role Rename and Clean Break

The old LevelOfAssurance enum (ANONYMOUS/EMAIL_VERIFIED/HARDWARE_TOKEN) is replaced by Role (GUEST/OPERATOR/CONTRIBUTOR/ADMIN/M2M_PEER/CREATOR/M2M_TRUSTED). LevelOfAssurance is kept as a backward-compat alias in both SDKs so existing code continues to import without changes, but the values are different — map your callsites before upgrading.

The deprecated message type aliases FEDERATION_SYNC, ALERT, and AUDIT are removed in rcan-ts. Update to the canonical names before upgrading.

---

What's Shipping Today

---

Migration Guide

1. Update your config

castor migrate --config robot.rcan.yaml
# or edit manually: rcan_version: "2.1"

2. Generate and sign your firmware manifest

castor attest generate
castor attest sign --key /path/to/robot-private.pem

3. Generate and publish your SBOM

castor sbom generate
castor sbom publish --token <your-rrf-token>

4. Enable the authority handler

# robot.rcan.yaml
authority_handler_enabled: true
audit_retention_days: 3650

5. Check your L5 status

castor doctor --json | jq '.rcan_v21'

SDK: update Role references

# Python — LevelOfAssurance is kept as an alias, but values changed
# Old: LevelOfAssurance.HARDWARE_TOKEN → New: Role.ADMIN or Role.CREATOR
from rcan.identity import Role
print(Role.ADMIN)   # 3

# TypeScript — FEDERATION_SYNC/ALERT/AUDIT removed
# Replace with canonical names: FLEET_COMMAND, FAULT_REPORT, TRANSPARENCY

---

What's Next

• RRF production deploy — KV namespace + signing key provisioning
• RCAN Foundation — California 501(c)(3) formation (opencastor-ops #9)
• Certification program — Tier 1 self-attestation ($99/device) launching once foundation is formed
• opencastor-client — Attestation card and compliance report screen live in the web app
• ISO/TC 299 liaison — Formal liaison application to TC 299 (rcan-spec #177 documented the normative references)