SHP certification is not a badge.
It is a cryptographically governed statement about a particular evaluated system state.
A certificate means that a defined device, in a defined state, was evaluated under defined SHP specifications and satisfied the applicable certification rules for a limited period of time.
Nothing more should be inferred from it.
Certification is not permanent.
It is not a guarantee that compromise cannot occur.
It is not created merely by running SHP verification tooling.
Certification describes a state
An SHP certification is bound to the context in which the certification decision was made.
Certification is:
- device-bound
- state-bound
- specification-bound
- time-bounded
Its meaning therefore depends on the stated:
- platform
- tier or certification class
- evaluated device
- evaluated state
- applicable specification versions
- scope
- exclusions, where permitted
- validity period
Change those conditions and the certification may no longer describe the current system.
Verification comes first
Certification does not begin with a certificate.
It begins with observed system state.
The relationship is:
Observed State → Evidence → Verification Result → Certification Decision → Signed Certification Artefact
Verification determines what the system actually satisfies.
Certification applies the governed certification rules to an eligible verification result.
These are related operations, but they are not interchangeable.
Certification is not permanent
An active SHP certification always has a finite validity period.
When that period ends, the certification becomes:
Expired — Not Certified
Expiry does not mean that the device was compromised.
It means that the previous certificate no longer represents an active SHP certification of the current system.
A certification may also become:
Revoked — Not Certified
Revocation and expiry are distinct lifecycle events.
Neither state constitutes active certification.
State change and drift
Certification is state-bound.
If material system state changes after certification, the certified state and the current state may diverge.
The applicable SHP drift rules determine the resulting certification status.
Where certification conditions are no longer satisfied, downgrade or invalidation is mechanical.
There is no discretionary mechanism for preserving certification merely because the change appears harmless.
Where re-verification is required, a new certification decision must be made before SHP certification can again represent the current state.
Full-tier certification
Full-tier certification means that the applicable requirements for that tier are satisfied under the governing platform specifications.
Tier status is not established by an informal security assessment.
It derives from the applicable:
- control catalogue
- Non-Negotiable Controls
- tier mathematics
- verification results
- certification decision rules
A tier number has meaning only within its platform-specific specification set.
Bounded certification
Where explicitly permitted by the applicable specifications, certification may cover less than a complete tier.
It must then be labelled:
Tier X — Bounded Certification
A bounded certification must identify:
- the controls included
- the controls excluded
- the residual risk created by those exclusions
It must never be presented as equivalent to full-tier certification.
Bounded certification cannot override the absence or failure of an applicable Non-Negotiable Control.
If an applicable NNC fails, the certification consequence follows the applicable tier rules.
Non-Negotiable Controls remain hard gates
NNCs exist to protect tier integrity.
They are not weighting factors.
They are not advisory controls.
They are not operator-discretion controls.
An applicable failed NNC cannot be compensated for by passing other controls.
It cannot be waived to preserve a certification result.
It cannot be hidden through bounded certification.
Certification authority
Running SHP verification tooling does not make the operator a certification authority.
SHP certification exists only when issued under SHP-controlled signing authority.
The SHP trust model is hierarchical.
At a high level:
SHP Root → Platform Intermediate → Operational Certification Signing Authority
The SHP root does not sign individual certification artefacts directly.
Platform separation is maintained through distinct platform intermediates.
Signing authority remains under SHP control.
Client self-signing does not constitute SHP certification.
Independent signatures over verification results do not become SHP certificates merely because the verification tooling is open.
The signed artefact
The authoritative certification object is the applicable machine-readable certification manifest covered by the certification signature.
The signed manifest binds the certification decision to the governed data required by the applicable certification specifications.
Human-readable certificates, pages, badges, or other representations are derived views.
They must not silently alter the meaning of the signed machine-readable artefact.
Cryptographic verification should establish:
- artefact integrity
- signature validity
- applicable trust chain
- certification identifier
- lifecycle status where applicable
- specification binding
- validity period
Public verification
SHP may provide a public verification service for checking certification status.
That service supplements cryptographic verification.
It does not replace it.
Public verification must not expose client identity merely to prove certification status.
Public certificate identifiers must be:
- non-sequential
- non-predictable
- salted and hash-derived under the applicable SHP rules
The public interface should expose certification status without revealing unnecessary information about the certified party.
Platform certification is platform-specific
Certification does not transfer automatically between platforms.
Fedora certification is not Wi-Fi certification.
Wi-Fi certification is not Network Gateway certification.
The same tier number on different platforms does not imply equivalent controls, attack resistance, or certification semantics.
Each supported platform has its own admitted specification set.
Platform support exists only through an Active Platform Admission Record.
Certification and service availability are different
A platform may be formally supported by SHP without production certification signing being operationally available.
These are separate states:
Platform Support
means the platform has been formally admitted under the SHP governance model.
Certification Signing Readiness
means the required operational trust infrastructure is available for issuing certification artefacts.
Service Availability
means certification services are actually being offered.
None of these states should be inferred from another.
What certification does not mean
SHP certification does not mean:
- compromise is impossible
- every conceivable threat is covered
- certification survives arbitrary state change
- an expired certificate remains active
- a revoked certificate remains valid
- one platform’s certification is equivalent to another’s
- independent execution of SHP tooling creates certification
- client-generated signatures constitute SHP certification
- SHP continuously monitors the certified system
- SHP provides incident response merely because a system was certified
- certification is a permanent property of a device
Certification must always be interpreted within its explicit bounds.
The specifications govern certification
This page explains SHP certification.
The applicable versioned certification specifications define its technical meaning.
Those specifications govern:
- evidence
- verification
- certification decisions
- tier mathematics
- bounded certification
- Non-Negotiable Controls
- signing authority
- trust chains
- lifecycle
- expiry
- revocation
- drift and invalidation
- public verification
Where explanatory website text and an applicable normative specification differ, the governing specification controls.