CRA Architecture v1.0
A sterile-first reference model for cyber recovery ready environments, based on three-plane separation, clean data ingestion through a forensic airlock, and non-persistent compute in a dedicated recovery site.
At a glance
- Scope: institutional recovery from systemic compromise
- Audience: architects, operators, regulators, assurance
- Focus: trust-first rebuild, not uptime-only failover
- Status: v1.0 draft reference
1. Purpose and scope
CRA Architecture v1.0 defines a minimum set of characteristics for an environment that can rebuild a compromised institution trust-first, not just uptime-first. It is technology-agnostic and complements existing backup and DR patterns rather than replacing them.
In scope
- Recovery from systemic identity, platform, and infrastructure compromise
- Design of a sterile recovery site and associated data flows
- Operating patterns for clean rebuild of critical services
- Evidence and artefacts to support regulatory dialogue
Out of scope
- Prevention and detection controls in production
- Traditional DR for “trusted outage” scenarios
- Vendor-specific implementations or product selection
- Detailed people/process playbooks (covered by CRA Body of Knowledge)
2. Threat assumptions
The architecture assumes a systemic compromise of the live estate. Production and DR are treated as contaminated until proven otherwise.
2.1 Compromise model
- Central identity (e.g. AD) is compromised or cannot be trusted.
- Hypervisors, orchestration, and management tooling may be tampered with.
- Backups in production/DR domains may contain malware or be incomplete.
- Threat actors may deliberately target recovery tooling, with delayed or logic-based triggers.
2.2 Design consequences
- Nothing in production or DR is accepted as trustworthy input by default.
- Recovery requires rebuild over restore of identity and core platforms.
- All inbound data into the recovery environment crosses a forensic airlock.
- Compute in the recovery site is non-persistent and sterile-by-default.
3. Conceptual reference model
The CRA architecture is based on three distinct estates that reflect the lifecycle of a cyber compromise. Together with the cyber recovery planes, they define how trust is lost, and how it is re-established.
Operational estate
The live production environment that delivers services to clients. Optimised for availability and performance, but not inherently resilient to systemic compromise.
Disaster recovery estate
A replica used for continuity and failover. It improves uptime, but cannot be assumed trustworthy once a widespread compromise or corruption of production is suspected.
Cyber recovery estate
A separate, sterile environment used to rebuild trust from known-good artefacts under tightly controlled identity, network, and data flows.
3.1 Planes of the CRA model
Control plane
- Recovery orchestration and workflow automation
- Privileged access and approvals for recovery actions
- Segregated identity and admin paths for recovery operators
- Authoritative configuration source for the recovery site
Data plane
- Immutable tertiary backups and recovery artefacts
- One-way ingestion pipelines from production and DR
- Malware scanning, integrity checks, and anomaly detection
- Promotion of “known-good” restore points via the forensic airlock
Network plane
- Segmentation between production, DR, vault, and clean site
- One-way or tightly mediated data flows into the recovery plane
- Dedicated admin access paths with device assurance
- Controlled egress during and after recovery activities
3.2 Trust posture
- Production & DR: treated as untrusted after systemic compromise.
- Vault / tertiary backup zone: a guarded storage zone where data is stored and validated but never executed.
- Clean recovery site: a sterile execution environment with tightly controlled ingress and egress, used to re-establish trust before services are reintroduced to the wider estate.
4. Zones and trust boundaries
CRA Architecture separates where data is stored from where it is executed. Storage only becomes trustworthy after verification; execution environments must start sterile and remain that way.
4.1 Production and DR zones
- Treated as contaminated after systemic compromise, even if apparently healthy.
- May be used for forensic evidence gathering, but not as a direct recovery platform.
4.2 Vault / tertiary backup zone
- Immutable storage for backups and recovery artefacts.
- One-way or policy-constrained connectivity from production.
- No interactive workloads: the vault is a storage-only trust anchor.
4.3 Sterile recovery substrate
- Pre-provisioned but logically empty compute, storage and network fabric.
- Built from golden images and configuration-as-code controlled by the CRA control plane.
- No inherited trust from production or DR identity systems.
4.4 Operator & validation workspaces
- Dedicated operator VDI / jump hosts.
- Isolated test environments to validate recovered workloads before exposure.
- Observation tooling (logs, metrics) sourced from the clean site, not from compromised domains.
5. Data flows and the forensic airlock
All data entering the clean site passes through a forensic airlock. The pattern is “pull, inspect, promote” instead of “push and trust”.
5.1 Ingestion from production
- Backups are taken from production into a vault / tertiary store.
- Immutable retention and write-once semantics are enforced.
- Backup images undergo malware scanning, integrity checking and anomaly detection.
- Candidate recovery points are flagged as eligible, not yet trusted.
5.2 Forensic airlock
- Data is pulled from the vault into an isolated staging area.
- Deep inspection is performed (content checks, rulesets, sandbox execution where appropriate).
- Recovery teams review results and approve or reject promotion.
- Approved data is rehydrated into the sterile recovery substrate under strict change control.
5.3 One-way egress during recovery
- Outbound connectivity from the clean site is tightly limited (e.g. regulator reporting, carefully controlled partner feeds).
- No default trust path is re-established back into compromised production until explicitly governed and re-baselined.
6. Operating patterns
The architecture is realised through operating patterns that favour rebuild-over-restore, separation of duties, and continuous rehearsal.
6.1 Non-persistent compute
- Application and database hosts are rebuilt from golden images and configuration-as-code.
- Identity platforms are reconstituted using audited recovery procedures.
- Application data is restored; system images are not treated as authoritative.
6.2 Separation of duties
- Recovery operators are distinct from production admins.
- Approval workflows are enforced for promotion of data, connectivity activation and cutover.
- Privileged actions are logged and preserved for review and regulatory reporting.
6.3 Continuous rehearsal
- Regular exercises into the clean site with representative workloads.
- Metrics feed into the CRA Maturity Model (Initial → Developing → Established → Exemplar).
- Gaps and findings feed back into design, tooling and process.
7. Regulatory alignment and assurance
CRA Architecture is intended to map to emerging regulatory language on tertiary backup, logical air-gapping and secure recovery environments. It provides a common reference for firms, vendors and supervisors.
Assurance outcome
An institution should be able to demonstrate that, after systemic compromise, it can rebuild critical services in a clean environment using known-good data, within defined time and data-loss tolerances, with an auditable trail of decisions.
7.1 Evidence classes
- Architecture diagrams showing three-plane separation and zones
- Network and access control patterns for the recovery site
- Immutable backup and retention configuration and policies
- Forensic airlock procedures and tooling configurations
- Recovery exercise reports mapped to CRA maturity levels
7.2 Relationship to CRA family
- Architecture: the target state reference model.
- CRABoK: operating practices, playbooks and patterns.
- Certification: individual and organisational competence.
- Maturity model: how progress is measured over time.
8. Next steps and versioning
CRA Architecture v1.0 is a draft reference. Future versions will deepen sector-specific guidance and link more tightly into implementation blueprints.
Planned evolution
- Publish a public change log and versioning scheme for CRA Architecture.
- Add sector profiles (e.g. FMIs, retail banking, critical national infrastructure).
- Connect explicit controls and artefacts into CRA certification and the maturity model.