Security Claims Engineering: How to Write Cybersecurity Claims That Actually Hold Up Under Scrutiny
The Gap at the Heart of Cybersecurity Assurance
The phrase "security claim" appears throughout every major cybersecurity regulatory instrument. The Cyber Resilience Act requires manufacturers to demonstrate that products comply with essential requirements. The NCSC CAF requires operators to demonstrate outcomes against fourteen security principles. IEC 62443 requires system integrators to specify achieved Security Levels for each zone and conduit. DORA requires financial entities to document their ICT risk posture and the effectiveness of controls.
In every case the regulatory instrument is asking for a structured assertion of security capability, a claim which is backed by evidence.
Yet despite the ubiquity of the word "claim" in regulatory frameworks, there is almost no guidance on how to construct one. The practice of formal security argument construction has been developed in specialist communities, Common Criteria evaluation, defence sector safety cases, the nuclear and aerospace industries but has not crossed into mainstream IT product security or managed service assurance.
The consequence is that most organisations, when asked to evidence their security posture to a regulator or procurer, produce documentation that fails the basic tests of a defensible claim. It is not falsifiable. It is not traceable to specific evidence. It does not address the circumstances under which it would be false. And it will not survive adversarial scrutiny.
Security Claims Engineering is the methodology for doing it properly.
What Makes a Security Claim Defensible
Consider the difference between these two statements about a connected industrial sensor:
Assertion: "The Acme X200 sensor is secure and has been penetration tested."
Engineered Claim: "The Acme X200 sensor (firmware v3.2.1 and above) does not expose any remotely exploitable vulnerability with a CVSS v3.1 base score of 7.0 or above via its Modbus TCP interface, as evidenced by CREST-certified penetration test report PT-2024-089, scoped to the Modbus TCP attack surface and conducted 14 November 2024, supplemented by automated SBOM vulnerability check SB-2024-007 conducted 20 November 2024. This claim applies when the device is deployed in a network segment isolated from untrusted networks in accordance with architecture document ARCH-2024-003, and is subject to review upon publication of any CVE affecting the Modbus TCP implementation."
The assertion cannot be evaluated, challenged or relied upon by any external party. The engineered claim can. A regulator, procurer or independent assessor can take it, locate the evidence, and make a rational judgement about whether the claim is valid and whether the evidence supports it.
The difference between those two statements is Security Claims Engineering.
The Seven-Element Claim Template
A well-formed security claim comprises seven mandatory elements. Each serves a specific function in making the claim defensible, auditable and reusable across regulatory and procurement audiences.
Claim Identifier. A unique reference enabling traceability across regulatory packages, evidence matrices and assessment reports. Format: [Organisation]-[Domain]-[Sequence], for example ACME-NET-001.
Claim Statement. A clear, falsifiable assertion of security capability. Must be specific (subject, property and scope clearly defined), falsifiable (it must be possible to demonstrate that it is false), grounded (it must correspond to something that can be evidenced), and bounded (it must not assert more than the evidence can support).
Security Principle. The regulatory requirement or security principle the claim addresses — not "CRA" in the abstract but "CRA Annex I §1(a)" specifically. The principle is the requirement; the claim is the assertion that the requirement is satisfied.
Rationale. The interpretive bridge between the regulatory requirement and the specific assertion. Explains what the principle requires, how the claim addresses it, and why this level of specificity is appropriate. Frequently omitted — and its absence is a common cause of regulatory challenge.
Evidence References. Traceable links to the specific artefacts that support the claim, each identified by unique artefact ID, evidence type, date, generating entity and EQF level.
Assurance Level. Whether the claim is self-attested, second-party reviewed, or independently validated. Must accurately reflect the independence of evidence generation — inflating assurance level beyond what the evidence supports is potentially misleading and creates regulatory exposure.
Scope Constraints. The precise boundaries within which the claim is valid: product versions, configurations, deployment environments and temporal bounds. Scope constraints are not admissions of weakness. They are honest characterisations of the claim's applicability that protect the claim author from challenge on grounds that the claim was applied outside its intended scope.
Claim Hierarchies: Decomposing Complex Regulatory Requirements
A top-level regulatory claim "the Acme X200 satisfies the essential cybersecurity requirements of CRA Annex I" cannot be directly evidenced by any single artefact. It decomposes into multiple sub-claims, each addressing a specific aspect of the requirement and each supported by specific evidence.
The three-level hierarchy makes this decomposition explicit and auditable.
Level 1 — Principle Claims address the regulatory requirement directly. Example: "The Acme X200 (firmware v3.2.1+) does not contain known exploitable vulnerabilities at the time of market placement (CRA Annex I §1(a))."
Level 2 — Domain Claims address specific security domains or attack surfaces that together constitute the Level 1 claim. Example: "The X200 Modbus TCP interface does not expose CVSS 7.0+ vulnerabilities." "The X200 web configuration interface does not expose CVSS 7.0+ vulnerabilities." "X200 firmware v3.2.1 third-party components contain no known CVEs with CVSS 7.0+ as of market placement date."
Level 3 — Evidence Claims are the most specific sub-claims, each directly supportable by a single named evidence artefact. Example: "Penetration test PT-2024-089, conducted by [Firm] on 14 November 2024, identified no CVSS 7.0+ vulnerabilities on the Modbus TCP interface of firmware v3.2.1."
This hierarchy serves three functions. It makes gap analysis tractable ,revealing exactly which properties must be evidenced and which evidence is missing. It enables parallel evidence generation, different sub-claims can be assigned to different teams. And it makes the assurance case auditable and an independent assessor can evaluate each sub-claim and its evidence independently before forming a view on the top-level claim.
Defeaters: Stress-Testing Claims Before Someone Else Does
A defeater is an argument, scenario or piece of information that, if true, would undermine the validity of a security claim. Security Claims Engineering requires systematic identification and response to defeaters before a claim is presented to any external audience.
There are four defeater types.
Rebutting defeaters argue that the claim statement itself is false. Example: a newly published CVE affects a component listed in the SBOM, rebutting the claim that the product contains no known exploitable vulnerabilities.
Undercutting defeaters argue that the evidence is insufficient to support the claim, without necessarily asserting it is false. Example: the penetration test was conducted before the latest firmware release and may not apply to the version currently on the market.
Scope defeaters argue that the claim has been applied outside its stated boundaries. Example: the claim is valid for isolated network deployment but the product is being marketed for direct internet connectivity.
Staleness defeaters argue that the claim was valid when made but is no longer current. Example: the threat model has not been updated since a new attack technique was published that applies to the product's architecture.
Identifying and documenting defeaters before submission — and demonstrating how each has been addressed — is the primary mechanism by which security claims become defensible under adversarial review. A claim presented without known defeaters addressed is potentially misleading. A claim that has been systematically stress-tested and patched demonstrates intellectual rigour that builds confidence in ways that a clean-looking but unexamined claim cannot.
How Claims Map to Regulatory Frameworks
One of the most practically significant benefits of Security Claims Engineering is its ability to serve multiple regulatory audiences from a single claim set. Because claims are structured around security principles rather than regulatory checklists, a single well-formed claim can simultaneously address requirements across multiple frameworks.
A claim that a product "provides authenticated firmware updates and rejects unsigned firmware packages" is simultaneously relevant to CRA Annex I §2(b), NIS2 Article 21(2)(f), CAF Principle B6, IEC 62443-3-3 SR 2.4, and ISO 27001 Annex A.8.25–29. Write the claim once, structure it properly, support it with evidence at the right EQF level — and it works for all of them.
This is the Overlap Dividend described in the companion Cyber Assurance Architecture paper, applied at the claim level. Organisations that design their claim registers around security principles rather than individual regulatory checklists achieve materially lower total compliance cost than those who build bespoke documentation for each framework.
Key Takeaways
Security Claims Engineering is the discipline of constructing, evidencing, stress-testing and maintaining structured security assertions across the product or system lifecycle.
The seven-element claim template — Identifier, Statement, Principle, Rationale, Evidence References, Assurance Level, Scope Constraints — is the complete structure for a defensible, auditable security claim.
Claim hierarchies decompose complex regulatory requirements into independently evidenceable sub-claims, enabling gap analysis, parallel evidence generation and structured assurance cases.
Defeater analysis — the systematic identification and response to arguments that would undermine a claim — is the primary mechanism by which claims become defensible under adversarial review.
The Claim-Evidence Traceability Matrix maps every claim to its evidence and every piece of evidence to the claims it supports. It is the operational backbone of a Security Claims Engineering programme.
Claims anchored to security principles rather than regulatory checklists are inherently portable across multiple regulatory frameworks. Write once, present to many.
A well-engineered claim set presented to a CRTF assessor dramatically reduces assessment cost and time — the assessor can focus on technical evaluation rather than reconstructing the claim structure from scratch.
Download the Full White Paper
The full Security Claims Engineering paper includes the complete seven-element claim methodology with worked examples; three sector case studies covering a connected medical device under CRA and MDR, an industrial PLC under IEC 62443, and a managed security service provider under NIS2 and DORA; the full defeater type reference guide; a multi-framework cross-reference matrix for worked example claims; a blank Security Claim Record template ready to use; and a full implementation checklist.
Free to download. No registration required.
Security Claims Engineering: How to Write Cybersecurity Claims That Actually Hold Up Under Scrutiny