Frequently Asked Questions
What is the Structured Hardening Project?
SHP is a structured hardening standard.
It connects explicit threat models, defined controls, hardening procedures, evidence, deterministic verification, and governed certification.
The purpose is to make a security posture defined and verifiable rather than relying on an informal statement that a system has been “hardened”.
Is SHP just a hardening guide?
No.
A guide can recommend configuration changes without establishing whether those changes were successfully applied or what their security meaning is.
SHP requires controls to define their purpose, application, verification, and recovery or rollback.
Verification results then feed the applicable certification rules.
Does SHP guarantee that a certified device cannot be compromised?
No.
SHP certification is deliberately bounded.
It represents satisfaction of applicable certification requirements under a defined threat model, scope, evaluated state, specification set, and validity period.
Threats outside those boundaries are not silently converted into certification claims.
What does an SHP tier mean?
A tier represents a defined hardening posture under the applicable platform specifications.
Tier numbers are not generic security scores.
The same tier number on two different platforms does not imply identical controls, threat coverage, operational constraints, or assurance.
The applicable platform specifications define the actual meaning.
What are Non-Negotiable Controls?
Non-Negotiable Controls, or NNCs, are mandatory certification gates where applicable.
An applicable NNC cannot simply be waived because other controls pass.
Bounded certification cannot be used to hide the absence or failure of an applicable NNC.
What is bounded certification?
Where the applicable specifications permit certification with defined exclusions, it must be labelled:
Tier X — Bounded Certification
The certification must identify the controls included, controls excluded, and residual risk.
Bounded certification is not equivalent to full-tier certification.
Is certification permanent?
No.
SHP certification is device-bound, state-bound, specification-bound, and time-bounded.
An expired certification is:
Expired — Not Certified
A revoked certification is:
Revoked — Not Certified
Material state change may also require re-verification under the applicable drift rules.
What happens when a certified system changes?
SHP treats relevant state change as drift.
The applicable rules determine whether that drift leaves certification unaffected, requires re-verification, causes downgrade, or otherwise invalidates the certification state.
A previous certification must not simply be assumed to describe a materially changed system.
Is verification the same as certification?
No.
Verification evaluates observed state against applicable SHP controls and evaluation rules.
Certification is a governed decision issued under SHP-controlled certification authority.
Running SHP verification tooling independently does not grant certification authority.
Can I verify an SHP certification independently?
That is a core design objective of the SHP model.
Verification tooling and machine-readable artefacts are intended to allow deterministic examination of the relevant evidence and certification material.
Public status verification may supplement that process, but it does not replace cryptographic verification of the certification artefact and its trust chain.
Can I sign verification output myself?
You may independently sign material that you control, but doing so does not create SHP certification.
Only certification issued under SHP-controlled certification authority constitutes SHP certification.
Client self-signing is outside the SHP certification trust boundary.
Does the SHP root key sign certificates directly?
No.
SHP uses a hierarchical trust model.
At a high level:
SHP Root → Platform Intermediate → Operational Certification Signing Authority
The root establishes trust in platform intermediates and does not perform routine signing of individual certification artefacts.
Which platforms does SHP support?
Platform support is explicit rather than assumed.
The public website currently describes the Fedora implementation and its Tier 1 threat model.
Additional platform domains may exist within the SHP specification corpus, but the existence of a specification does not automatically mean that a complete implementation or public certification service is available.
Current availability must be stated explicitly.
Can SHP controls be copied from one platform to another?
Not by assumption.
A control valid for one platform may rely on different threat assumptions, system behaviour, implementation mechanisms, or verification evidence from another.
New platform support requires formal platform definition and an explicit threat model before certification controls can be established.
Is SHP a managed security service?
No.
SHP certification is not continuous monitoring, general IT support, or incident response.
Certification services establish and evaluate a defined hardening state under the applicable SHP standard.
Does passing verification mean a device will definitely be certified?
Not necessarily.
Certification depends on the complete applicable decision rules, including scope, control results, Non-Negotiable Controls, certification eligibility, and other requirements defined by the applicable specifications.
Verification evidence is an input to certification rather than an independent grant of certification authority.
Does publishing a specification mean the corresponding service is available?
No.
Specification status and service availability are separate.
A document can define architecture, mathematics, controls, or a platform domain without implying that SHP currently offers public certification for it.
Who defines SHP certification requirements?
The applicable versioned SHP specifications define the requirements.
The website explains those requirements but does not override them.
Certification services operate under the standard rather than redefining it.