Security is not a single feature and it is not solved by putting a transaction on a ledger. The Blockcontrol security model is built around evidence: who acted, under which authority, on which source state, through which controlled route, with what result and with which proof that another authorised party can independently verify.
1. The executive security decision
Before approving an IBDCP deployment, a decision-maker should be able to answer five questions: who can act, where keys are held, what data is exposed, how state changes are proven and how incidents or configuration changes can be recovered and audited.
| Decision question | IBDCP principle | Evidence expected |
|---|---|---|
| Who is allowed to act? | Zero-trust identity, authority and least privilege | Role/capability policy, signed identity context, approval trail |
| Where are critical keys? | Protected institutional custody | HSM/MPC or approved custody profile, rotation/revocation procedure |
| What sensitive data moves? | Minimum necessary disclosure | Data classification, off-chain source location, disclosure/policy map |
| Can an auditor reconstruct the event? | Signed, tamper-evident evidence | Before/after digests, Matrix ID, policy result, verifier/finality evidence |
| Can the system change safely? | Versioned governance and change control | Versioned schemas, adapters, policies, cryptographic profiles and test results |
2. Security of this public website
The supplied website package intentionally keeps its browser-side attack surface small. It uses local assets, a restrictive Content Security Policy, no third-party advertising scripts, no iframes and no embedded remote fonts. Contact traffic uses only documented same-origin endpoints with signed challenges, rate limits, strict validation and one-time email verification before inbox delivery.
3. IBDCP production security architecture
A production IBDCP implementation should secure web/API access, service identities, signing, custody, evidence, personal data, administrative actions and external adapters. Core controls include:
- zero-trust service authentication and independent authorisation of users, services and devices;
- least-privilege roles and capability policies;
- protected institutional key custody such as HSM/MPC-backed signing services;
- signed submissions and authenticated source evidence;
- tamper-evident event and audit records;
- encryption of sensitive data in transit and at rest;
- rate limiting, abuse detection and anti-automation controls;
- independent audit, conformance and security testing;
- recovery, revocation and key-rotation procedures.
4. Data protection: minimum necessary data with maximum verifiability
IBDCP does not require sensitive PII, KYC documents, banking details, medical records or confidential business documents to be copied into a public ledger. Sensitive data should generally remain in the relevant authoritative system, with the interoperability layer carrying only what is necessary to verify the decision: cryptographic digest, issuer/reference, status, policy result and purpose-bound evidence.
5. Keys, signing and institutional custody
Long-lived raw private keys should not be exposed in ordinary application or orchestration memory. Institutional signing should be performed through a scoped signing/custody service, such as HSM/MPC-backed infrastructure or another approved custody profile. Capability to sign should be bound to actor, operation, destination, transaction context and time window where appropriate.
6. Evidence before trust is assumed
Every material state-changing operation should be attributable and reconstructable. Depending on the deployment profile, evidence can include actor identity, source-state digest, instruction/intent digest, policy result, adapter/version, verifier attestations, before/after state, settlement/finality evidence and completion timestamp.
The goal is not more logging. The goal is a proof object another authorised party can use to verify what happened without relying only on the application screen that displayed it.
7. Governance and change control
Security can be invalidated by an invisible configuration change. Schemas, policy profiles, cryptographic profiles, adapters, routing manifests and other execution-critical artefacts should therefore be versioned. Material proofs should identify the relevant versions so an auditor can determine which rules and code paths governed the event.
8. Cryptographic agility and post-quantum readiness
Long-lived evidence may outlive today’s cryptographic assumptions. IBDCP therefore treats cryptographic profiles as governed and replaceable rather than hard-coding one algorithm forever. Post-quantum-ready profiles can be applied where the risk horizon justifies them, with explicit algorithm/version identification and migration procedures.
Post-quantum claims should be tied to the actual cryptographic profile in use, not to topology labels or marketing terminology.
9. Security boundary: what IBDCP does not replace
IBDCP adds transaction-level verification and evidence. It does not remove the need for secure endpoints, hardened cloud infrastructure, IAM, patch management, vulnerability management, secrets management, backup/restore, monitoring, incident response, secure SDLC, supplier controls and jurisdiction-specific regulatory safeguards.
10. Production assurance
For a production decision, Blockcontrol recommends defining a deployment-specific security profile and acceptance criteria covering threat model, data classification, identity/authority, key custody, cryptography, APIs, infrastructure, logging/evidence, recovery, business continuity, penetration testing and independent conformance testing.
Assess your business case to define the smallest deployment that can prove both commercial value and security fit before scaling.
11. Responsible security disclosure
If you believe you have identified a vulnerability in a Blockcontrol-controlled public system, please report it privately through the verified Security contact route, which is routed server-side to security@ibdcp.blockcontrol.com. Include the affected URL/component, steps to reproduce, impact and any non-destructive supporting evidence. Do not access data that is not yours, disrupt service or publish an unremediated vulnerability without coordination.