TC-15 Secure configuration and hardening of PoC components
| Objective | TC-15 |
| Evidence level | Evidence, Integrate |
| Domain | Security and risk fit |
| Owner | Raidiam for the platform and the demonstration components. CBA standards apply to the Formal Proof of Concept environment, with ID Partners delivering. |
| Phase | Formal Proof of Concept |
| Proven by | content-hardening |
On what is claimed here. Where this document describes the demonstration, it states what the Enhanced Vendor Demo of 24 August 2026 is built to prove, not what has already been built, recorded or verified. Status for every scene is tracked in objectives/tc-objectives.yaml.
1. What CBA asked for
Secure configuration and hardening of PoC components.
2. Scoping the answer honestly
There are three different estates in this engagement and they attract three different standards. Mixing them produces either an overclaim or an irrelevance, so they are separated here.
| Estate | What it is | Standard that applies |
|---|---|---|
| The Raidiam Connect platform | The product. Multi tenant service on AWS, operated by Raidiam, already carrying production traffic for schemes including ConnectID. | Raidiam's production security standard. Assurance artefacts are supplied through ID Partners on request (see section 6). |
| The demonstration components | The reference authorization servers, resource servers, agent provider and visualisers built for 24 August 2026. Vendor hosted, synthetic data, no CBA integration, no CBA network connectivity, torn down after use. | Proportionate hardening, described in section 4. Not CBA's standard operating environment, and not presented as such. |
| The Formal Proof of Concept environment | CBA integrated, with Ping, Entra, SIEM and network in scope. | CBA's standards. ID Partners delivers against them and CBA's controls apply. This is not built and nothing about it is asserted here. |
The rest of this document is about the middle row, because that is the estate that exists between now and the demonstration.
3. What the demonstration estate is, in risk terms
Vendor hosted, entirely synthetic data, no connectivity into or out of the CBA network, no CBA credentials, no CBA data, no contract dependency, and a defined end date. The strongest control on it is not a hardening setting: it is that there is nothing of CBA's inside it and no path from it to anything of CBA's. That is stated first because it is the fact that determines how much of the rest matters.
4. Hardening applied to the demonstration components
| Control | Position |
|---|---|
| Transport | TLS on every endpoint. No plaintext listeners. |
| Default credentials | None. Nothing ships with a default administrative credential, and no component has an unauthenticated administrative interface. |
| Secrets | Held in the platform's managed secret configuration, injected at runtime. Not in the repository, not in images, not in environment files committed to git. |
| Dependencies | Pinned by lockfile. Builds are reproducible from the lockfile rather than resolving latest at build time. |
| Base images | Pinned, and rebuilt from a current base on each deployment rather than carried forward. |
| Configuration | Declared in code and applied by pipeline, so configuration drift is visible as a diff rather than discovered. This is the same property that makes the environment rebuildable (content-recovery.md). |
| Attack surface | Each component exposes only the endpoints its scene requires. The resource servers accept tokens and nothing else. |
| Data | Synthetic throughout. No production data, no CBA data, no personal data of real people. |
| Lifetime | The environment has a defined end and is torn down rather than left running, which removes the unmaintained demonstration environment risk entirely. |
| Labelling | Every non Raidiam runtime component is visually labelled as a reference implementation standing in for the CBA estate, so nothing in the demonstration is mistaken for a product being offered. |
5. What is deliberately not claimed
Stated plainly, because a credible answer needs a boundary.
- The demonstration components are not built to CBA's standard operating environment.
- They have not been penetration tested for this engagement.
- They are not in scope of CBA's vulnerability management or configuration compliance tooling.
- No CIS benchmark or equivalent baseline has been asserted against them.
- They are reference implementations built to demonstrate a protocol interaction, not products.
None of that applies to the Raidiam Connect platform itself, which is a production service and is covered by section 6.
6. What CBA will want for the Formal Proof of Concept, and where it comes from
The following are documentation requests rather than build work, and they route through ID Partners as the contracting party.
- Raidiam's platform security documentation and its hardening baseline.
- Current independent assurance artefacts and certification status, supplied under the appropriate agreement.
- The most recent penetration test summary for the platform, and the remediation position.
- Change and release process, including how a security relevant change reaches production.
- Secure development practices, including code review, dependency policy and build integrity.
For the Formal Proof of Concept environment specifically, CBA and ID Partners should agree, before build:
- Which CBA hardening baseline applies to which component, and who evidences compliance.
- Whether CBA's configuration compliance tooling is pointed at any part of the environment.
- The review point at which the environment is signed off as fit to hold CBA data.
7. Status
Proportionate hardening is applied to the demonstration estate as described in section 4. The Formal Proof of Concept hardening position is not built, is CBA standard driven, and is ID Partners delivered.