CAF Principle B4: System Security
CAF principle B4 asks whether your systems are built, configured and maintained to limit an attacker’s opportunities, covering design, configuration, management and vulnerabilities. It connects to the Cyber Security and Resilience Bill (CSRB) because some security duties require regard to the state of the art.
The Bill is not yet law. Regulation and section references come from the Bill as brought from the Commons (HL Bill 32). The Lords has since amended the Bill, so numbering and detail may change in the final Act. This guide is general information, not legal advice.
What B4 asks
B4 in the National Cyber Security Centre's Cyber Assessment Framework (CAF) is the most directly engineering-focused principle. It uses your understanding of risk to decide how to limit an attacker's opportunities. For the Cyber Security and Resilience Bill (CSRB), it is where a claim that security is "appropriate to the risk" gets tested against how the systems really work.
| Outcome | Core idea |
|---|---|
| B4.a Secure by Design | Minimise attack surface, so that one vulnerability cannot stop the function |
| B4.b Secure Configuration | Known, consistent, minimal settings you can rebuild |
| B4.c Secure Management | Trusted administration, current documentation, malware controls |
| B4.d Vulnerability Management | Know your exposure, then mitigate and test |
Design and recovery belong together
B4.a links some design choices you might not expect. Simple data flows are expected in part because they make monitoring easier. Systems are also expected to be designed so they are easy to recover. Security zones, inspection or sanitisation of content-based attacks, and boundary defences all sit here too.
A useful test for one important function: which single vulnerability, if exploited, would stop it? If you can name one, B4.a's description suggests your design has more work to do.
Automated decision-making
B4.a and B4.b both address automated decision-making technologies at the achieved level. You are expected to design restrictions that stop them taking actions that could harm your systems, understand how they operate, and be able to replicate decisions. The NCSC says CAF v4.0 improves coverage of AI-related cyber risks across the framework. This could apply to AI agents with administrative permissions, so review what they can do unaided.
What can show it
These are our suggestions, not NCSC requirements:
- Architecture diagrams showing zones, boundaries and data flows
- Baseline build definitions, plus drift reports comparing live systems against them
- Change records for security boundaries
- An application allow-list, and confirmation that only permitted software can install
- Vulnerability tracking showing dates announced, prioritised and mitigated
- Reports from regular testing, including third-party tests at the achieved level
- A register of unsupported systems, with mitigations and migration dates
Where organisations fall short
- Internet from essential systems: browsing and email are reachable from them.
- Bypassed controls: remote or third-party access skips network controls.
- Weak rebuild information: configuration records cannot support rebuilding a system.
- Default accounts: generic or built-in accounts remain active.
- Admin from ordinary devices: systems are maintained from devices that are not corporately owned and managed.
- Nothing tested lately: no recent test checks your understanding of your own vulnerabilities.
How B4 relates to the Bill
The Bill's text does not name the CAF, and the CAF is not itself legislation. For RMSPs, regulation 14B says measures must ensure a level of security appropriate to the risk, having regard to the state of the art, and must prevent and minimise the impact of incidents. B4's outcomes offer one structured way to consider what that means for your systems.
Records from B4 may also help during an incident. Full notifications need information about the nature of the incident, and accurate configuration, change and vulnerability records can help you establish that within the 72-hour window. Keep in mind that the full notification only requires this information so far as it is known.
Next, read CAF 4.0 explained, the CAF self-assessment guide and our overview of the framework.
Sources
Frequently asked questions
B4.a Secure by Design, B4.b Secure Configuration, B4.c Secure Management and B4.d Vulnerability Management.
The wording in B4.a and B4.b refers to automated decision-making technologies. At the achieved level, you should apply restrictions to prevent harmful actions, understand how they operate and be able to replicate decisions.
B4.d asks for prompt mitigation rather than giving a set number of days. Your own policy should define what prompt means based on risk.
At partially achieved, you have temporary mitigations while pursuing migration to supported technology. Failing to mitigate them, or not pursuing a replacement, is a warning sign.