Structured Hardening Project
How SHP Is Different
How the Structured Hardening Project differs from security benchmarks, frameworks, audits, hardening guides, and configuration tools.
Security already has frameworks, benchmarks, hardening guides, assessment tools, audits, and configuration automation.
SHP does not exist because those things are useless.
It exists because they answer different questions.
A benchmark can tell you how a system should be configured.
An assessment tool can evaluate particular configuration requirements.
A cybersecurity framework can help an organisation understand and manage cybersecurity risk.
A hardening script can automate configuration changes.
SHP asks something narrower:
Can this specific system prove that it satisfies a defined hardening standard in its current evaluated state?
That distinction is the reason SHP exists.
From guidance to a verifiable state
SHP treats hardening as a chain:
Threat Model → Controls → Hardening → Evidence → Verification → Certification
Each stage has a different purpose.
The threat model defines the security problem and platform boundary.
Controls define the required hardening state.
Hardening applies those controls.
Evidence records relevant observed state.
Verification evaluates that evidence against the applicable requirements.
Certification applies the governed certification rules to an eligible verification result.
No stage silently substitutes for another.
How does SHP compare?
| Approach | Primary purpose | Fundamental question |
|---|---|---|
| Security benchmark | Define recommended or required configurations | How should this technology be configured? |
| Cybersecurity framework | Structure cybersecurity outcomes or risk management | How should cybersecurity risk or outcomes be organised and managed? |
| Security audit | Assess a defined scope against stated criteria | What did the assessment find within its scope? |
| Hardening guide or script | Describe or automate configuration changes | What should be changed, or what can be automated? |
| SHP | Define, verify, and govern certifiable hardening postures | Does this device state satisfy the applicable SHP requirements? |
These approaches are not interchangeable.
Nor does SHP need them to be inferior for SHP to have a purpose.
They operate at different levels, under different scopes, and answer different questions.
SHP is concerned with the verifiable hardening state of a specific device within a formally admitted SHP platform.
The difference is what happens after hardening
Installing a hardened configuration is not the end of the SHP process.
Neither is running a scanner.
Neither is passing a checklist.
For SHP, the resulting state must be capable of being evaluated against the applicable published requirements.
That creates two important distinctions:
Hardening ≠ Verification
and:
Verification ≠ Certification
A system may be hardened without being verified.
A system may be verified without receiving SHP certification.
Running SHP verification tooling does not itself create SHP certification.
SHP certification exists only when issued under SHP-controlled signing authority.
A certificate describes a state — not a machine forever
SHP certification is deliberately bounded.
It does not mean:
“This machine is secure.”
An SHP certification represents satisfaction of applicable certification requirements for a defined device, evaluated state, specification context, scope, and validity period.
Certification is:
- device-bound
- state-bound
- specification-bound
- time-bounded
Change relevant state and the previous certification may no longer describe the current system.
Allow certification to expire and it becomes:
Expired — Not Certified
Revoke it and it becomes:
Revoked — Not Certified
Applicable drift can also result in re-verification, downgrade, or invalidation according to the governing rules.
That behaviour is intentional.
Security state changes. Certification has to acknowledge that.
Understand SHP Certification →
No hidden judgement call
Same supported evidence. Same versioned rules. Reproducible result.
SHP verification is designed to be deterministic.
Certification outcomes derive from structured verification results and the applicable published certification rules.
They are not based on an assessor deciding that a system looks “secure enough”.
That does not mean every system passes.
It means the result must follow from the evidence and the governing rules.
Uncertainty is not silently converted into success.
Mandatory conditions are not averaged into a percentage.
Applicable Non-Negotiable Controls cannot be waived merely because other controls pass.
Don’t take our word for it
SHP deliberately separates trust from assertion.
The standard is public.
Its requirements are versioned.
Verification is designed to be open and reproducible.
Certification decisions derive from governed verification results.
Certification artefacts are designed for independent cryptographic verification under the SHP trust architecture.
The proposition is not:
“Trust us. We’re security experts.”
It is:
“Here are the rules. Here is what was evaluated. Here is the certification result. Verify it.”
What SHP is not
SHP is not:
- a guarantee against compromise
- a claim of universal security
- a generic security checklist
- a vulnerability scanner
- a percentage-based security score
- general IT support
- a managed security service
- incident response
- an excuse to call every security activity “certification”
It does one deliberately narrow thing:
SHP defines hardening requirements for formally admitted platforms and provides a governed way to verify and certify whether a particular system state satisfies those requirements.
And, as promised:
We won’t help you set up your printer.
You say the system is hardened.
Can you prove it?
That is the question SHP is designed to answer.
Define it. Harden it. Verify it. Certify it. Re-verify when required.
Have a system you want to harden?
If your system falls within a supported SHP platform, we can determine whether it fits the applicable hardening and certification boundary.
You do not need to work out the tier, specification set, or certification eligibility before contacting SHP.
Explore the SHP Standard →
View Supported Platforms →
Understand Certification →
Read the Specifications →