HodeiShield®

Your security posture, verifiable by whoever asks for it.

A regulated customer, an auditor or your board asks for proof of your maturity per framework. The Trust Center publishes it with public or controlled access; ATTEST adds a signed document anyone can check offline, with no account.

Request a demoSee the verifier on GitHub (opens in a new tab)
  • ML-DSA-65 (FIPS 204) signature in a detached JWS, no certificate authority
  • Open-source verifier (Apache-2.0) that works offline

attestation.json

Sample data

Protected header

alg
ML-DSA-65
typ
application/attest+jws
kid
q3Vn…8aLw

Signed claims

slug
organisation-a
visibility
public
generatedAt
09:00:00Z
expiresAt
09:15:00Z
  • NIS2 Substantial
  • ENS Basic
  • DORA Substantial

Overall band: Basic, the weakest

Validity15 min by default
09:0009:15

Output of verify-attestation.sh

PASS  alg is ML-DSA-65 (RFC 9964, IANA-permanent)PASS  ML-DSA-65 signature verifies over protected.payloadPASS  not expiredPASS  overallBand (E6) 'basic' equals the weakest attested band — recomputed, not trustedVERIFIED — this document was signed by the holder of the key above and has not been altered since.That is all it proves. It does not prove the claims inside are true, that the key belongs to who you think, or that the document was meant to exist.
Sample data: the organisation, the times and the identifiers are fictional. The verifier output is shown verbatim.

Two pieces that work together

The Trust Center is the page your counterpart sees. ATTEST is the signed proof they can take away and check on their own.

Trust Center

  • A page with public or restricted access (NDA / manual review) depending on the content.
  • An audit trail of access requests and events.
  • Update subscriptions with double opt-in.
  • Coverage per framework and your public documentation in one place.

ATTEST

  • A document signed on demand with ML-DSA-65 (FIPS 204), as a detached JWS.
  • Only the maturity band for each framework and the weakest one: never scores, euros or vendor detail.
  • Short-lived: 15 minutes by default and one hour at most, with an optional challenge-response.
  • Revocation of a key, or of an organisation's earlier attestations, through a signed status list.

From a published Trust Center to a VERIFIED anyone can reproduce

None of this requires a HodeiShield account for the person verifying.

  1. You publish the Trust Center

    An attestation is issued for a published Trust Center, public or access-controlled. There is no scheduled job and no store: the document is signed at the moment it is requested.

  2. Whoever needs it requests the attestation

    It is requested from your organisation's public endpoint. With a nonce of their own, the response is bound to that request.

    curl -s https://app.hodeishield.com/api/public/attest/<slug> -o attestation.json

  3. They download the public keys

    The verification keys are published at an open endpoint.

    curl -s https://app.hodeishield.com/api/public/attest/keys -o keys.json

  4. They verify offline

    verify-attestation.sh checks the signature and expiry and recomputes the overall band. It only needs bash 4, OpenSSL 3.5 and python3.

    ./verify-attestation.sh --attestation attestation.json --jwks keys.json

Verification does not call HodeiShield. The one exception is optional: the status-list mode, if you point it at an https URL yourself.

What an attestation proves and what it does not

It is a maturity self-assessment signed by HodeiShield. This is exactly what the signature adds.

What it proves

  • Integrity: the document has not been modified since it was signed.
  • Origin: it was signed by the holder of the published key.
  • Time: when it was issued and until when it is valid.

What it does not prove

  • That what is attested is true: it is a self-assessment, not an independent verification.
  • Compliance or certification: it does not replace an audit, ISO 27001, the ENS or any other accredited certification.
  • A transparency log, or a root of trust beyond TLS and pinning the published key.
  • Revocation of individual attestations: a key or an organisation is revoked, and the short lifetime makes up for the rest.

Every claim, with its proof and its scope

What HodeiShield says about ATTEST and the Trust Center, and where you can check it.

  1. Every published Trust Center can issue an attestation signed with ML-DSA-65 (FIPS 204) as a detached JWS.

    Docs · Attestation verifier (opens in a new tab)

    Scope. It signs maturity claims; it does not check them.

  2. It attests the maturity band of each framework (four bands) and the weakest one. Never scores, euro amounts or vendor detail.

    In the demo

    Scope. A band is not an audit result.

  3. It is verified offline with the open-source verifier (Apache-2.0) and the public keys, using bash 4, OpenSSL 3.5 and python3.

    GitHub · hodeishield-attest-verifier (opens in a new tab)

    Scope. It recomputes the overall band; it does not validate that the claims inside are true.

  4. An attestation is short-lived: 15 minutes by default and one hour at most.

    In the demo

    Scope. With an optional challenge-response to bind the answer to the requester.

  5. A signed, published status list can revoke a key or all of an organisation's earlier attestations.

    Docs · Attestation verifier (opens in a new tab)

    Scope. It does not revoke individual attestations.

  6. The Trust Center is public or restricted (NDA / manual review), keeps an audit trail of requests and events, and its subscriptions use double opt-in.

    Docs · Trust Center guide (opens in a new tab)

    Scope. What you publish and who you grant it to is your decision.

Keep going

Verifier documentation (opens in a new tab)Verifier repository (opens in a new tab)Verifier in the browser (opens in a new tab)

Questions about ATTEST and the Trust Center

The ones asked by people who have to rely on an attestation, and by those who have to issue it.

Does an attestation replace an audit or a certification?

No. It is a maturity self-assessment signed by HodeiShield. It proves integrity, origin and time of issue, not that what is attested is true. It does not replace an audit, ISO 27001, the ENS or any other accredited certification.

What exactly does my customer see?

The maturity band of each framework (four bands) and the weakest one. Never scores, euro amounts or detail about your vendors.

Does my customer need a HodeiShield account to verify it?

No. They download the public keys and run the open-source verifier (Apache-2.0), which works offline with bash 4, OpenSSL 3.5 and python3.

How long does it last, and what if a key is compromised?

Fifteen minutes by default and one hour at most. A signed status list can revoke a key or an organisation's earlier attestations; it does not revoke individual attestations, and the short lifetime makes up for that.

Does the Trust Center have to be public?

No. It can be public or restricted (NDA / manual review). Access requests and events are kept in an audit trail.

Why ML-DSA-65?

It is the signature algorithm standardised in FIPS 204. It is used to sign attestations; it does not protect live traffic.

What certifications do you hold?

Hodeitek S.L., the company behind the product, is certified to ISO/IEC 27001 and to Spain's ENS at Medium category (certificate no. 34/5704/26/09103, OCA Instituto de Certificación), with a scope that includes the HodeiShield SaaS service. We do not certify your organisation's compliance: we measure it.

See an attestation issued and verified

In the demo we publish a sample Trust Center, issue an attestation and verify it offline, with your mix of frameworks.

Prefer to check it first? The verifier and the documentation are public.

Request a demoRead the verifier documentation (opens in a new tab)