Structured Hardening Project (SHP) Charter

Version 2.0 — Structured, Bounded, Verifiable, and Certifiable

Status: Active

Authority Level: S1 — Absolute

Amendment Classification: Major

Supersedes: SHP Charter v1.0

Effective Date: 23 September 2026

1. Purpose

The Structured Hardening Project (SHP) defines and maintains a structured, versioned hardening standard for explicitly admitted computing and infrastructure platforms.

SHP establishes:

• platform-specific hardening specifications;
• explicit threat models;
• tiered or otherwise formally defined security postures;
• Non-Negotiable Control definitions;
• drift and downgrade governance;
• deterministic verification models;
• evidence requirements;
• cryptographic certification binding;
• certification lifecycle rules; and
• public trust and verification requirements.

SHP may provide certification services under the SHP standard.

Certification is a service provided under the standard. It does not constitute regulatory authority, insurance, a warranty of invulnerability, or a guarantee against compromise.

SHP is a structured hardening standard and certification framework.

It is not a general IT support service, managed security service, incident-response service, or general-purpose systems administration service.

2. Platform Scope

2.1 Platform-Specific Architecture

SHP operates through explicitly defined platform specifications.

No platform is implicitly supported.

The existence of:

• a threat model;
• a control catalogue;
• a mathematical model;
• experimental tooling;
• draft documentation;
• a website page;
• implementation work; or
• historical SHP material

does not by itself establish a platform as supported for SHP certification.

A platform must be formally admitted under SHP governance before certification may be issued for that platform.

2.2 Platform Admission

Formal platform admission requires, at minimum:

1. an explicitly defined platform boundary;
2. an explicit threat model;
3. applicable platform mathematics or other formally authorised certification model;
4. defined control requirements;
5. identified Non-Negotiable Controls where tiers or equivalent certification classes are used;
6. deterministic verification requirements;
7. evidence requirements;
8. drift, downgrade, invalidation, expiry and revocation rules;
9. recovery requirements;
10. certification lifecycle rules;
11. an approved trust-chain position; and
12. formal governance approval of the platform as supported.

Where any required component is incomplete, contradictory or unverified, platform admission shall not be inferred.

2.3 Platform Admission Record

Formal platform support exists only where an Active Platform Admission Record exists under SHP governance.

For a platform P:

Supported(P) = true

if and only if an applicable Platform Admission Record exists with status Active.

In all other cases:

Supported(P) = false

An Active Platform Admission Record must identify, at minimum:

• the platform identifier;
• the platform scope and boundary;
• the effective admission version;
• the applicable specification set;
• the applicable threat-model reference;
• the applicable certification model;
• the applicable platform intermediate trust reference;
• the admission effective date; and
• the admission status.

Platform Admission Record states must be governed by a lower-level normative SHP specification consistent with this Charter.

Publication of a Platform Admission Record in any state other than Active does not establish platform support.

Absence of an Active Platform Admission Record means the platform is unsupported for SHP certification.

Unsupported platforms shall not receive SHP certification.

Platform support must therefore be machine-resolvable from governed SHP records and must not depend on implication, marketing language, historical documentation or informal representation.

The Charter shall not require amendment merely to add, suspend, withdraw or supersede a platform where the platform-admission mechanism itself remains unchanged.

2.4 Platform Separation Rule

Each admitted platform is a distinct technical domain.

Each platform must define its own applicable:

• specification;
• threat model;
• controls;
• certification model;
• verification behaviour;
• evidence requirements;
• drift rules;
• recovery rules; and
• cryptographic trust boundary.

There is:

• no automatic cross-certification;
• no assumed tier equivalence;
• no assumed control equivalence;
• no assumed threat-model equivalence; and
• no assumed security-posture equivalence between platforms.

A tier identifier has meaning only within the platform and specification that defines it unless a higher-authority SHP specification explicitly defines otherwise.

2.5 Unsupported, Proposed and Experimental Platforms

An unsupported platform shall not receive SHP certification.

Experimental, proposed or draft platform work must be clearly distinguished from formally supported platforms.

Publication of platform-related material does not establish:

• platform support;
• certification availability;
• implementation completeness;
• certification eligibility; or
• signing authority.

A platform adapter, verifier module, control catalogue, threat model or other technical artefact may exist for an unsupported platform without changing Supported(P).

3. Specification Transparency and Authority

3.1 Public Normative Rule

Any rule capable of changing an SHP certification outcome must be publicly defined in applicable versioned normative material.

Certification shall not depend on secret or opaque:

• eligibility rules;
• control requirements;
• evaluation predicates;
• scoring mechanisms;
• NNC definitions;
• downgrade thresholds;
• refusal predicates;
• certification-state transitions; or
• discretionary exceptions.

Given the published normative specifications, applicable structured evidence and deterministic verification output, the certification decision must be reproducible.

Opaque certification logic is prohibited.

3.2 Public Reproducibility Requirement

Normative material necessary to reproduce an SHP certification decision must be publicly available in version-bound form.

This includes, where applicable:

• evaluation predicates;
• control definitions;
• NNC classifications;
• control mappings;
• dependency rules;
• evidence schemas;
• verification schemas;
• tier or certification-class eligibility rules;
• drift classifications;
• downgrade predicates;
• refusal predicates;
• lifecycle transition rules; and
• verifier source necessary to reproduce normative evaluation behaviour.

A third party must be able to determine, from the applicable published specifications, structured evidence and versioned verifier implementation, why a certification decision was reached.

Public reproducibility does not grant certification authority.

Independent reproduction of a verification or decision result does not constitute SHP certification.

3.3 Permitted Internal Material

SHP may maintain non-public operational material where publication would be unnecessary or would weaken operational security.

Such material may include:

• private cryptographic keys;
• certificate-ID salts;
• credentials and secrets;
• internal recovery material;
• physical key-storage procedures;
• internal administrative checklists;
• infrastructure configuration containing secrets;
• operational incident information;
• non-normative implementation notes; and
• other security-sensitive operational material.

Internal material must not secretly alter certification meaning or eligibility.

Where an internal procedure affects a certification outcome, the normative rule producing that effect must be publicly defined.

3.4 Specification Authority

SHP specifications operate under a defined authority hierarchy.

The Charter is the highest SHP authority.

Lower-authority specifications must conform to this Charter.

Where a lower-authority document conflicts with this Charter, the Charter prevails and the conflict must be treated as a specification-integrity failure requiring correction.

A lower-authority specification cannot modify this Charter by implication.

4. Certification Model

4.1 Certification Is Bounded

SHP certification is always bounded.

Certification applies only within:

• the applicable platform boundary;
• the applicable threat model;
• the certified device;
• the verified configuration state;
• the referenced specification versions;
• the referenced verification tooling version where applicable; and
• the defined validity period.

Certification must never be represented as permanent or universal.

4.2 Time-Bounded Certification

All certifications are time-limited.

The applicable specification must define the validity period.

Upon expiration, certification status becomes:

Expired — Not Certified

Expiry does not imply compromise.

Expired certification may be referenced historically but must not be represented as current certification.

Certification does not automatically renew.

Re-certification requires verification under the specifications applicable to the new certification decision.

4.3 Device-Bound Certification

All SHP certification is device-bound.

Certification must bind to a platform-defined device reference sufficient to distinguish the certified target without requiring public disclosure of sensitive hardware identity.

Certification shall not:

• certify an individual;
• represent personal competency;
• transfer merely because device ownership changes; or
• imply certification of other devices.

4.4 State-Bound Certification

Certification binds to a verified configuration state.

Platform specifications must define which state changes:

• remain within certification validity;
• require re-verification;
• cause downgrade;
• cause certification invalidation; or
• require revocation.

Material state change must not be silently treated as continued certification.

4.5 Version-Bound Certification

Every certification must reference the governing versions necessary to interpret its meaning, including:

• Charter version;
• platform specification version; and
• verification tooling version where applicable.

Historical certification meaning remains bound to those versions.

Subsequent specification amendments do not retroactively redefine an earlier certificate except where an explicitly security-critical rule requires invalidation or revocation.

5. Certification Lifecycle State

5.1 Internal Lifecycle State

SHP shall maintain a deterministic certification lifecycle state model richer than the state exposed through public certificate lookup.

Applicable normative specifications shall define the complete state set, transition function, event set, precedence rules and externally observable consequences.

The lifecycle model may contain states including:

• Unevaluated;
• Evaluated;
• Eligible;
• Certified;
• Conditional;
• Downgraded;
• Revoked;
• Expired;
• Unsupported;
• Refused;
• Reverification Required; and
• other formally specified internal lifecycle states.

Lifecycle states and transitions that affect certification decisions must be deterministic and publicly defined.

5.2 Internal State Is Not Public Disclosure

The existence of an internal lifecycle state does not require that state or its associated metadata be exposed through the public verification service.

Internal lifecycle semantics and public disclosure semantics are separate concerns.

5.3 Public Certification Status

The public verification mechanism shall expose only the public states authorised under Section 16.

Internal states must not be projected into public disclosure unless a normative specification explicitly authorises that disclosure consistently with this Charter.

6. Non-Negotiable Controls

6.1 NNC Definition

Each tiered platform specification must identify the Non-Negotiable Controls applicable to each tier.

NNCs define controls without which the certification posture cannot exist.

6.2 NNC Hard Gate

If any applicable NNC is unsatisfied:

• that tier shall not be certified;
• bounded certification shall not override the failure;
• discretionary approval is prohibited; and
• the certification decision shall mechanically downgrade to the highest eligible lower tier where one exists.

Where no lower certification state is eligible, certification shall not be issued.

NNC absence cannot be waived.

6.3 Public NNC Requirement

NNC definitions must be:

• public;
• versioned;
• unambiguous;
• distinguishable from non-NNC controls; and
• directly mappable to deterministic verification requirements.

A change to NNC meaning requires controlled specification versioning.

7. Bounded Certification

7.1 Permitted Use

Where an applicable platform specification permits bounded certification, a certification may exclude otherwise applicable non-NNC controls only under explicitly defined rules.

NNCs cannot be excluded.

7.2 Mandatory Contents

Every bounded certification must:

1. identify its parent tier;
2. enumerate included controls;
3. enumerate excluded controls;
4. state the residual risk introduced by exclusions;
5. reference the applicable specification versions;
6. remain device-bound;
7. remain state-bound;
8. remain time-bounded; and
9. remain cryptographically bound.

7.3 Mandatory Label

Bounded certification must be labelled:

Tier X — Bounded Certification

where X is the applicable platform-local tier identifier.

Bounded certification must never be represented as equivalent to full-tier certification.

Terms that obscure the bounded nature of certification are prohibited.

7.4 Full-Tier Integrity

Full-tier certification remains the canonical complete posture for a defined tier.

Bounded certification cannot redefine the tier.

8. Verification

8.1 Deterministic Verification

SHP verification must be:

• publicly reproducible;
• deterministic;
• versioned;
• reproducible;
• auditable; and
• machine-readable.

Given identical supported platform state, specification version, verifier version and evidence inputs, deterministic evaluation must produce the same result.

8.2 Structured Output

Verification tooling must produce structured machine-readable output sufficient to derive the certification decision.

Applicable specifications must define:

• control result states;
• evidence requirements;
• evaluation criteria;
• failure behaviour;
• drift classification;
• downgrade triggers; and
• refusal or unsupported states.

8.3 Certification Decision Traceability

Every certification decision must map directly to verification output and applicable published rules.

Human discretion shall not convert a failed deterministic requirement into a passing certification outcome.

Manual evidence collection may be permitted where formally specified, but evaluation of that evidence must remain governed by deterministic rules.

8.4 Verification Is Not Certification

Verifier output does not itself constitute SHP certification.

A device may independently reproduce or obtain verification results without becoming SHP-certified.

Official certification exists only after issuance under SHP-controlled signing authority.

9. Control Discipline

Every SHP hardening control must define:

1. what the control does;
2. how the control is applied;
3. how the control is verified; and
4. how the control is recovered, reversed or otherwise safely remediated.

A proposed control lacking verification or recovery is not a valid SHP certification control.

Every control must map to a defined threat or explicitly defined security property.

Controls without threat or security-property justification shall not be included merely because they appear security-related.

SHP shall prefer supported, auditable and reproducible mechanisms over undocumented or theatrical hardening.

10. Evidence

10.1 Evidence Principle

Certification must be supported by evidence sufficient to reproduce the certification decision.

Evidence requirements must be:

• defined by applicable specifications;
• control-mapped;
• integrity-protected;
• provenance-preserving;
• deterministically interpretable;
• machine-interpretable where required; and
• sufficient to distinguish failure from absence, error, unsupported state or insufficient evidence.

Evidence integrity failure shall not be treated as a successful control result.

10.2 Evidence Abstraction Boundary

This Charter mandates the properties required of certification evidence.

It does not mandate a permanent concrete:

• evidence-object schema;
• serialisation format;
• hashing algorithm;
• signing algorithm;
• storage format; or
• transport mechanism.

Those mechanisms must be defined by applicable lower-authority normative specifications and must satisfy the requirements of this Charter.

Changing a concrete evidence mechanism does not require amendment of this Charter unless the constitutional evidence properties defined here are changed.

10.3 Evidence Integrity and Provenance

Applicable evidence specifications must define mechanisms sufficient to establish:

• evidence identity;
• source or provenance;
• capture context;
• integrity;
• verifier relationship;
• applicable control relationship;
• applicable version relationship; and
• deterministic interpretation.

Where authenticity is required, the applicable specification must define the cryptographic mechanism used to establish it.

10.4 Evidence Retention

Evidence retention requirements must be defined by applicable certification governance.

Retention must be sufficient to preserve certification auditability and historical meaning for the required governance period.

11. Drift, Downgrade and Invalidation

11.1 Drift Taxonomy

Each admitted platform must define a deterministic drift taxonomy.

The taxonomy must identify which changes:

• preserve certification;
• require re-verification;
• cause downgrade;
• invalidate certification; or
• trigger revocation.

11.2 Mechanical Classification

Drift classification is mechanical.

Discretionary override of a deterministic downgrade or invalidation condition is prohibited.

11.3 Automatic Downgrade

Where verified state no longer satisfies the certified tier but satisfies a lower tier, the applicable certification rules shall determine the downgrade mechanically.

NNC failure shall always be handled according to the NNC hard-gate rule.

11.4 State Invalidation

Where a material state change makes the certified state no longer applicable, the previous certification must not be represented as certification of the changed state.

Re-verification is required where specified.

12. Revocation

Certification may be revoked under formally defined conditions including:

• signing-key compromise;
• fraudulent verification;
• evidence-integrity failure;
• incorrect issuance;
• security-critical specification invalidation; or
• other explicitly defined revocation predicates.

Revoked certification status shall be:

Revoked — Not Certified

Revocation is distinct from expiration and downgrade.

13. Cryptographic Certification Architecture

13.1 Exclusive Signing Authority

Official SHP certification may be issued only under SHP-controlled signing keys.

Client-generated or third-party signatures:

• do not constitute SHP certification;
• cannot modify SHP certification status; and
• cannot substitute for SHP issuance.

13.2 Hierarchical Trust Model

SHP shall maintain a hierarchical cryptographic trust model:

SHP Root Key
↓
Platform Intermediate Key
↓
Certification Signing Key
↓
Signed Certification Manifest

The SHP Root Key:

• is the ultimate trust anchor;
• must be maintained offline;
• must never sign end-entity certification manifests directly; and
• signs platform intermediate keys.

Each formally admitted platform must use a separate platform intermediate.

Platform intermediates must not be shared between platform certification domains.

Operational certification signing keys must chain through the applicable platform intermediate to the SHP Root.

13.3 Root Trust Reference

The SHP Root public trust reference must be publicly available through an SHP-controlled publication mechanism.

Cryptographic verification requires validation of:

• the certification signature;
• the signing-key chain; and
• the chain’s relationship to the published SHP Root trust reference.

13.4 Key Lifecycle

Key generation, storage, rotation, revocation and recovery must be governed by versioned SHP cryptographic procedures.

Key compromise must trigger the applicable deterministic revocation and trust-recovery processes.

14. Certification Artefacts

14.1 Dual-Format Structure

SHP certification must consist of:

• a machine-readable certification manifest;
• a detached cryptographic signature covering that manifest; and
• a human-readable representation derived from the authoritative manifest.

The machine-readable manifest is the authoritative certification object.

14.2 Manifest Requirements

The manifest must contain sufficient structured information to establish, as applicable:

• certificate ID;
• device reference;
• platform;
• tier or certification class;
• certification type;
• issuance timestamp;
• expiration timestamp;
• certification state at issuance;
• Charter version;
• platform specification version;
• verification tooling version;
• verification/evidence binding;
• signing-key reference; and
• trust-chain reference.

The manifest must be deterministically serialised according to an applicable specification.

The detached signature must cover the complete authoritative manifest.

14.3 Human-Readable Certificate

The human-readable certificate must visibly identify:

• certification posture;
• Full or Bounded status where applicable;
• platform;
• issuance date;
• expiration date;
• applicable specification references; and
• sufficient trust information to locate the cryptographic verification path.

Expiration must be visible and must not depend solely on hidden metadata.

15. Certificate Identification and Privacy

15.1 Certificate IDs

Certificate IDs must be:

• cryptographically hash-derived;
• non-sequential;
• non-predictable;
• non-reversible with respect to device identity; and
• unsuitable for deriving hardware identifiers.

Certificate IDs must incorporate SHP-controlled secret material.

15.2 Per-Platform Salt Compartmentalisation

Certificate-ID salts must be separate per platform.

A salt must not be reused across platform certification domains.

Salt compromise in one platform must not enable certificate-ID derivation or correlation in another platform.

Salt rotation and recovery must be governed internally without exposing the salt itself.

16. Public Verification

16.1 Public Status Service

SHP shall maintain a public certification-status verification mechanism for issued SHP certification.

The public verification mechanism shall expose only:

• certificate ID; and
• certification status.

The public certification status values defined by this Charter are:

• Certified
• Expired — Not Certified
• Revoked — Not Certified

Additional publicly disclosed certification states require a Charter-consistent normative specification explicitly authorising them.

16.2 Privacy Boundary

The public verification mechanism must not disclose:

• client identity;
• device identity;
• hardware identifiers;
• platform;
• tier;
• specification details;
• verification evidence;
• configuration state; or
• other information capable of unnecessarily identifying or profiling a client or device.

16.3 Internal/Public State Separation

Internal lifecycle states such as:

• Evaluated;
• Eligible;
• Conditional;
• Downgraded;
• Unsupported;
• Refused; or
• Reverification Required

shall not automatically become public certificate-status values.

The public verification mechanism exposes status only.

16.4 Cryptographic Authority

The public verification service supplements cryptographic verification.

It does not replace it.

Authenticity ultimately depends on verification of the signed machine-readable manifest against the SHP trust chain.

17. Threat Model Discipline

17.1 Explicit Threat Models

No platform shall be certified without an explicit applicable threat model.

The threat model must define relevant:

• adversary capabilities;
• attack surfaces;
• assumptions;
• exclusions;
• environmental boundaries; and
• residual risk.

17.2 Tier Meaning

Tiers represent formally defined platform-local security postures.

They are not consumer ratings, quality scores, or universal “good/better/best” rankings.

A numerically higher tier on one platform does not imply equivalence to the same number on another platform.

17.3 No Absolute Security Claim

SHP does not claim:

• invulnerability;
• impossibility of compromise;
• absolute protection;
• universal protection against nation-state adversaries; or
• elimination of operational risk.

Claims must remain bounded by the applicable threat model and verified controls.

18. Recovery

Every control must have a defined recovery, reversal or remediation path appropriate to its function.

Applicable platform specifications must define recovery behaviour sufficient to avoid uncontrolled or undocumented hardening states.

Where recovery changes certified state, the applicable drift and re-verification rules apply.

19. Service Boundary

SHP certification is not:

• general IT support;
• printer or peripheral support;
• managed security;
• continuous monitoring;
• general systems administration;
• forensic investigation;
• incident response unless separately and explicitly provided outside certification;
• a warranty; or
• a guarantee of future security.

Certification is a bounded technical attestation under the SHP standard.

SHP must distinguish certification from any separately provided service.

Service availability does not alter certification requirements.

20. Data Minimisation

SHP shall collect only information necessary for:

• verification;
• certification binding;
• certification issuance;
• certification lifecycle management; and
• legitimate governance or audit requirements.

SHP certification processes shall not require collection of unrelated personal content.

Public certification verification shall not become a telemetry or client-tracking mechanism.

21. Technical Claim Discipline

SHP technical claims must be based on:

• authoritative upstream documentation;
• official platform documentation; or
• tested behaviour under defined conditions.

Where a technical proposition has not been sufficiently established, it must be identified as:

Unknown / Requires Testing

Version-specific behaviour must be identified where material.

Unsupported assumptions must not be promoted to certification requirements.

22. Deployment and Automation

Applicable platform specifications must define:

• deployment methodology;
• automation boundaries;
• verification tooling;
• evidence collection;
• drift evaluation; and
• recovery procedures.

Manual procedures may be used where automation is inappropriate or impossible, but must be documented sufficiently to remain reproducible and verifiable.

Deployment convenience must not override certification requirements.

23. Human Factors

Hardening reduces defined technical risk.

It does not eliminate:

• phishing;
• credential misuse;
• unsafe operator behaviour;
• social engineering;
• operational error; or
• threats outside the applicable threat model.

Certification does not substitute for competent operation.

24. Documentation and Representation

24.1 Technical and Public Parity

Public claims must not exceed the guarantees supported by applicable SHP specifications.

A certification service must not be represented as available where the necessary platform, verification and signing infrastructure is not operationally available.

24.2 Prohibited Guarantee Language

SHP certification must not be represented using claims such as:

• “unhackable”;
• “invulnerable”;
• “zero compromise”;
• “nation-state proof”; or
• equivalent absolute-security language.

24.3 Specification Publication

Draft, active, superseded, obsolete or withdrawn material must be clearly distinguishable.

Publication of a document does not itself make that document active or authoritative.

Publication metadata must accurately identify document status and authority.

25. Specification and Certification Change Control

25.1 Version Semantics

SHP specifications must use controlled versioning.

Version changes must distinguish material changes from non-functional clarification.

A material change that alters certification meaning requires an appropriate version increment and dependency review.

25.2 Non-Retroactivity

Specification changes shall not silently alter the meaning of previously issued certification.

Historical certification remains interpretable according to its referenced specification versions.

Retroactive invalidation is prohibited unless an explicitly identified security-critical condition requires revocation or invalidation.

25.3 Dependency Review

Changes to higher-authority specifications require review of dependent lower-authority specifications.

A lower-authority document may not silently override a higher-authority change.

Specification conflicts must be identified and resolved through controlled amendment.

26. Organisational Independence

SHP is a structured hardening standard and certification framework independent of any particular individual.

The SHP standard:

• is governed through documented processes;
• does not depend on personal identity for technical validity;
• is anchored to versioned specifications and cryptographic trust infrastructure; and
• must remain recoverable under defined governance procedures.

Operational control of signing authority must be documented, recoverable and transferable under SHP governance.

No individual identity constitutes the SHP trust anchor.

27. Binding Scope

This Charter governs all SHP specifications, certification systems, verification systems, certification representations and SHP-issued certification artefacts.

Any lower-authority SHP material inconsistent with this Charter must be treated as requiring reconciliation.

A conflicting lower-authority document does not amend this Charter by implication.

28. Charter Amendment Governance

28.1 Amendment Requirements

Every Charter amendment must:

• increment the Charter version;
• identify the amendment as Major or Minor;
• include a dated change record;
• define its effective date; and
• preserve historical Charter versions.

28.2 Major Amendments

A Major amendment includes a change that materially alters:

• certification rules;
• NNC governance;
• signing governance;
• platform-admission governance;
• certification authority;
• certification lifecycle semantics;
• public trust architecture; or
• other constitutional SHP behaviour.

Major amendments require review of dependent SHP specifications.

28.3 Minor Amendments

Minor amendments include:

• clarifications;
• language improvements;
• correction of non-functional errors; and
• changes that do not alter certification meaning.

A Minor amendment must not be used to conceal a material governance change.

28.4 Historical Meaning

Charter amendments shall not retroactively rewrite certification meaning.

Previously issued certification remains bound to the Charter and specification versions referenced at issuance except where an explicitly security-critical condition requires revocation.

29. Transition from Charter v1.0

Charter v2.0 is a Major amendment to Charter v1.0.

The principal constitutional changes are:

1. removal of hard-coded supported-platform declarations from the Charter;
2. establishment of explicit formal platform-admission governance;
3. establishment of the Active Platform Admission Record as the authoritative platform-support predicate;
4. removal of platform-specific certification classes from the Charter;
5. strengthening of the public normative transparency requirement;
6. explicit prohibition on secret rules capable of changing certification outcomes;
7. explicit separation of public normative rules from legitimate operational secrets;
8. explicit separation of publication from platform admission, service availability and certification eligibility;
9. explicit separation of internal certification lifecycle states from public certificate-status disclosure;
10. consolidation of device-, state-, time- and version-bound certification principles;
11. preservation and clarification of hierarchical per-platform signing authority;
12. preservation and clarification of NNC hard-gate behaviour;
13. preservation and clarification of bounded-certification requirements;
14. abstraction of evidence requirements from concrete evidence algorithms and schemas; and
15. strengthening of specification dependency and conflict-resolution requirements.

Charter v1.0 remains part of the historical SHP record.

It must not be altered to retrospectively reflect Charter v2.0.

Certifications, if any, issued under Charter v1.0 retain the meaning established by the versioned specifications applicable at issuance, subject only to explicitly security-critical revocation rules.

30. Effective Status

SHP Charter v2.0 — Active

Effective from 23 September 2026.

From this effective date, Charter v1.0 is:

SHP Charter v1.0 — Superseded

Superseded does not mean erased, invalid historical material, or retroactively rewritten.

It means that v1.0 is no longer the current Charter for new SHP certification decisions.

31. Change Record

Version 2.0 — 23 September 2026

Classification: Major

Charter v2.0 establishes the revised constitutional governance model described in Section 29.

It introduces formal platform admission, strengthens deterministic and publicly reproducible certification governance, formalises hierarchical per-platform trust boundaries, separates internal lifecycle state from public certification status, preserves NNC and bounded-certification integrity, and establishes explicit dependency reconciliation requirements for lower-authority SHP specifications.

This version supersedes Charter v1.0 from its effective date.

End of Structured Hardening Project Charter v2.0