The Structured Hardening Project exists because the phrase “this system has been hardened” is usually far too vague.
Hardening only becomes meaningful when the underlying questions are explicit:
- What platform is being evaluated?
- What threat model applies?
- Which controls are required?
- How are those controls implemented?
- How is their resulting state verified?
- What happens when mandatory controls fail?
- What exactly is certified?
- When does that certification stop representing the current state?
SHP turns those questions into a governed technical standard.
It does one narrowly defined thing, and we’re taking that thing all the way to the end.
What SHP is
SHP is a structured hardening standard.
It defines how bounded security postures are specified, implemented, verified, evaluated, and certified.
The model connects:
Threat Model → Controls → Hardening → Evidence → Verification → Certification
Each stage has a separate role.
The standard defines the rules.
Verification evaluates observed state.
Certification records a governed result.
Services may apply that standard, but they do not redefine it.
Why SHP exists
Security configuration is easy to describe informally.
It is much harder to make precise, reproducible, and independently examinable.
A checklist can say what somebody recommends.
A deployment script can say what somebody intended to configure.
Neither, by itself, proves what state currently exists.
SHP is built around the idea that a hardening claim should be capable of being traced through defined rules and evidence.
The objective is not to make vague claims stronger.
It is to make them narrower, explicit, and verifiable.
Threat model first
SHP does not begin by collecting security settings.
It begins by defining the security problem.
A platform threat model establishes the relevant boundary, adversaries, attack classes, protected objectives, assumptions, constraints, and exclusions.
Controls are then defined within that context.
This matters because a control cannot be meaningfully described as “secure” in isolation from the threat model it is intended to address.
Controls must be complete
An SHP control must define:
- What it does
- How it is applied
- How it is verified
- How it is recovered or rolled back
A control without verification or recovery is incomplete for SHP purposes.
This prevents hardening from becoming a collection of settings that can be applied but not reliably evaluated or reversed.
Verification before assertion
SHP treats verification as part of the hardening model.
It is not an optional final inspection.
Verification is intended to be:
- open
- deterministic
- versioned
- reproducible
- structured in machine-readable output
The same supported evidence evaluated under the same versioned rules should produce reproducible results.
Uncertainty must not be silently converted into success.
Certification is bounded
SHP certification does not mean:
“This device is secure.”
It means that a defined device state satisfied defined certification requirements under defined specifications for a limited period of time.
Certification is:
- device-bound
- state-bound
- specification-bound
- time-bounded
Expiry ends active certification.
Revocation ends active certification.
Material drift can invalidate the state that was originally certified.
Certification is never permanent.
Understand SHP Certification →
Tier integrity matters
SHP tiers are governed platform-specific hardening postures.
They are not security scores.
Applicable Non-Negotiable Controls are hard certification gates.
They cannot be ignored, averaged away, or bypassed through discretionary judgement.
Where bounded certification is permitted, it must remain explicitly bounded and must identify its included controls, excluded controls, and residual risk.
Bounded certification does not become equivalent to full-tier certification merely because most controls pass.
Platform discipline
SHP does not assume that security controls transfer safely between platforms.
Platform support is explicit.
A platform becomes supported only through an applicable Active Platform Admission Record.
Documentation, experimental work, tooling, testing, or control catalogues do not independently establish support.
A new platform must define its own boundary and threat model before certification controls can be established for it.
Open verification, controlled certification
SHP deliberately separates the ability to examine verification logic from the authority to issue certification.
Verification tooling is intended to be independently inspectable and reproducible.
Certification authority remains governed under the SHP trust architecture.
Running SHP verification tooling does not create SHP certification.
Client self-signing does not create SHP certification.
Certification exists only when issued under SHP-controlled signing authority.
Governance matters
SHP specifications are versioned and governed.
Changes must preserve historical meaning.
A certification issued under one specification set must not silently change meaning because a later version was published.
Amendments, supersession, lifecycle state, specification binding, and historical interpretation are therefore part of the standard itself.
Governance is not separate paperwork around the technical system.
It is part of what makes certification interpretable.
What SHP is not
SHP is deliberately narrow.
It 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
- continuous monitoring
- incident response
- an excuse to call every security activity “certification”
And, importantly:
We won’t help you set up your printer.
That boundary is deliberate.
SHP exists to define, verify, and certify structured hardening postures.
It does not exist to become a general IT support business.
Standard and service are separate
The Structured Hardening Project is the standard.
Certification is a service that may be delivered under that standard.
Those roles remain distinct.
The standard defines the requirements.
Hardening applies the controls.
Verification evaluates the observed state.
Certification records the governed result.
Services provide a mechanism for carrying out that work.
Service delivery must not weaken, redefine, or bypass the standard.
SHP is specification-driven
The website explains SHP.
The specifications define it.
The applicable versioned specifications govern:
- authority
- platform boundaries
- threat models
- control catalogues
- tier mathematics
- evidence
- verification
- certification
- trust architecture
- platform admission
- lifecycle
- amendment rules
Where explanatory website text and an applicable normative specification differ, the governing specification controls.