SHP verification asks one question:
Does the observed system state satisfy the applicable SHP controls under the defined evaluation rules?
Verification does not ask what was intended.
It asks what state actually exists.
It is separate from both hardening and certification.
Hardening is not verification
Applying a configuration does not prove that the required state exists.
A deployment procedure may fail.
A dependency may change.
A system may drift.
The observed state may differ from the intended state.
SHP therefore requires every certifiable control to define how its resulting state is verified.
A control without a defined verification method is incomplete for SHP certification purposes.
Verification begins with observed state
The verification path is:
Observed State → Evidence → Control Evaluation → Verification Result
Verification operates on evidence derived from the actual system state.
It does not treat deployment success, operator intention, or configuration history as proof that a control currently passes.
Evidence must retain enough context to support the applicable evaluation rules and downstream certification decision.
Deterministic evaluation
SHP verification must be designed so that the same supported inputs, evaluated under the same versioned rules, produce reproducible results.
Verification logic must not depend on hidden judgement.
Verification tooling must be:
- open
- deterministic
- versioned
- reproducible
- capable of structured machine-readable output
A verifier must expose enough structure for its result to be independently examined and reproduced.
Opaque verification logic is incompatible with the SHP model.
Evidence is not interchangeable with assertion
Verification cannot rely on the statement:
“This control was applied.”
It must evaluate evidence capable of establishing whether the required state exists.
Evidence may include platform-specific observations defined by the applicable specifications.
Where evidence is:
- unavailable
- insufficient
- unsupported
- erroneous
- indeterminate
- outside the verifier’s defined capability
the verifier must preserve that distinction according to the applicable evaluation rules.
Uncertainty must not be silently converted into success.
Control evaluation is explicit
Each applicable control is evaluated under its own defined verification rule.
Control evaluation is not a percentage-based security score.
A large number of passing controls does not automatically compensate for a failed mandatory condition.
Control results feed the applicable platform, tier, NNC, and certification decision rules.
The verifier must preserve the semantics required by those rules.
Non-Negotiable Controls
Applicable Non-Negotiable Controls retain their hard-gate semantics during verification and certification.
A verifier must not:
- downgrade an NNC failure into a warning
- average an NNC failure into a percentage
- hide an NNC result behind an overall score
- convert a failed NNC into a passing certification outcome
NNC semantics are part of tier integrity.
Machine-readable output
Verification output is intended for deterministic downstream processing.
The output must be structured so that certification decisions can map directly to the verification result and applicable decision rules.
The chain should remain examinable:
Evidence → Control Result → Tier / NNC Evaluation → Certification Eligibility
The result must not depend on logic that exists only inside an opaque operator process.
Version binding
Verification has meaning only under defined versions of the applicable rules.
A verification result therefore depends on the relevant versioned:
- platform specification
- threat model
- control catalogue
- verification logic
- evaluation language
- tier mathematics
- certification decision rules
A result produced under one specification set must not be silently treated as though it were produced under another.
Version binding is part of reproducibility.
Unsupported state must remain visible
SHP verification must distinguish between a condition that has been evaluated and failed and a condition that could not be validly evaluated.
Where the applicable specification requires a distinct unsupported, unknown, erroneous, or indeterminate state, that state must remain explicit.
A verifier must not convert missing knowledge into a passing result.
Where technical behaviour remains unresolved during specification or tooling development, the SHP rule is:
Unknown / Requires Testing
Such uncertainty must be resolved before it can support certification.
Verification does not equal certification
Open verification tooling may be independently executed.
Anyone may inspect the logic and examine its output.
That does not create SHP certification.
Verification answers whether the observed state satisfies the applicable evaluation rules.
Certification additionally requires:
- an eligible verification result
- the applicable certification decision logic
- satisfaction of NNC and tier requirements
- applicable lifecycle conditions
- issuance under SHP-controlled signing authority
Running the verifier yourself does not make you a certification authority.
Client self-signing does not constitute SHP certification.
Understand SHP Certification →
Drift and re-verification
Verification describes observed state at the time of evaluation.
If relevant system state changes, an earlier result may no longer represent the current system.
SHP therefore treats drift according to defined rules.
Where drift invalidates certification or requires re-evaluation, the affected system must be re-verified before a new certification decision can represent its current state.
A historical passing result is not proof that the same control still passes now.
Verification and platform boundaries
Verification is platform-specific.
The existence of a verifier for one platform does not imply support for another.
Verification behaviour must follow the admitted platform specification set.
No platform is supported merely because tooling exists for it.
Platform support exists only through an Active Platform Admission Record.
Independent examination
The SHP verification model is intended to make the evaluation path independently examinable.
A third party should be able to determine, from the applicable specifications, tooling version, evidence, and structured output:
- what was evaluated
- under which rules
- which controls passed
- which controls failed
- which conditions were unsupported or indeterminate
- how tier and NNC semantics were applied
- how the verification result relates to certification eligibility
This is why deterministic and structured output matters.
Public verification is different
Public certification verification and system-state verification are different functions.
System-state verification evaluates observed technical state.
Public certification verification confirms the status or authenticity of an issued certification artefact.
The public verification service supplements cryptographic verification.
It does not replace the underlying verification process or independently re-evaluate the system.
The specifications govern verification
This page explains the SHP verification model.
The applicable versioned specifications define its technical behaviour.
Those specifications govern:
- evidence
- control evaluation
- deterministic execution
- structured output
- version binding
- tier evaluation
- NNC semantics
- unsupported and indeterminate states
- certification eligibility
- drift and re-verification
Where explanatory website text and an applicable normative specification differ, the governing specification controls.