Security-conscious infrastructure by design.
Trust infrastructure is only as strong as the claims it can prove. ANANKE's security is built into every record, every state change, and every verification — not layered on top. Organizational data is isolated, key material never leaves its custody boundary, and every action leaves a traceable, tamper-evident record.
How your records are protected
Six properties that apply to every record issued through ANANKE — across Trust, T-CODE, and Sign.
Every record is cryptographically sealed at issuance
When a document or item is issued, its contents are hashed and bound to a signed record. Any modification — however minor — produces a different fingerprint. Tampering is structurally detectable, not a matter of policy.
State changes form a cryptographic chain
Lifecycle transitions — issuance, suspension, revocation — are linked in a cryptographic chain by the trust infrastructure. States cannot be silently inserted, removed, or reordered. The full history of a record is verifiable from any point in its chain.
Records are anchored to an external ledger
Cryptographic commitments are periodically anchored to Hedera Hashgraph's consensus service — an independent external ledger. This provides proof of when a record existed and what it contained, without publishing the record or its contents to any public network.
You decide what verifiers see
Verification is not public. Authorized verifier organizations access only the fields your disclosure policy permits. Different verification contexts expose different information. Nothing is visible to verifiers unless your policy says so.
Physical items carry offline-verifiable codes
T-CODE stamps link physical items to their digital trust record through a cryptographically signed barcode. The barcode payload is self-contained — it can be checked for authenticity without a network connection, then optionally confirmed online.
Protected signing services support Trust and T-CODE
Internal signing and remote trust-service mechanisms support the protected evidence created by Trust and T-CODE. ANANKE Sign is not offered as a public standalone product.
What we store, and what we don't
Transparency about data handling starts with being clear about what touches our systems.
What we store
What we never publish or expose
Infrastructure you can ask about
How the platform is built — for security teams, IT reviewers, and compliance auditors who want to go deeper. These are design goals and current implementation choices, not certifications.
Important: No certifications have been obtained. ANANKE Trust and T-CODE are not qualified trust services. ANANKE Sign is in development. These are engineering design goals only.
Keys & signing
Key custody and signing operations
Audit & continuity
Tamper-evident audit infrastructure
Identity & access
Authentication, authorization, and session management
Access control and authentication
Controlling who can access what, and proving it.
Each team member has specific permissions based on their role. Administrators, issuers, verifiers, and auditors each see and do only what they need to. Permissions are enforced at the platform layer, not just the UI.
Built-in OpenID Connect authentication with ANANKE's own identity provider. Tokens are cryptographically signed with 15-minute access token lifetimes and rolling refresh tokens. TOTP multi-factor authentication using authenticator apps is available, with organization-level enforcement, brute-force lockout, and one-time recovery codes.
API keys are secured using industry-standard hashing. The raw key is shown once at creation and never stored; only a hashed representation and metadata are retained. Keys are scoped to your organization and can be rotated at any time.
Access tokens expire after 15 minutes. Refresh tokens are rolling and valid for 7 days — a consumed refresh token cannot be reused. Rate limiting is applied at the network edge to protect login endpoints and the API against brute-force and credential-stuffing attacks.
What ANANKE does not claim
Credibility requires staying below the line of proof. These are not caveats — they are hard limits that protect you from relying on capabilities we do not provide.
Not public or anonymous verification
Verification runs through the ANANKE account model. Verifier access requires an approved organizational account. Verification results are not publicly accessible by design.
No hardware security module certification
Key management is isolated in a dedicated software KMS. No certified HSM hardware is claimed. No FIPS or hardware security certification is asserted.
Not certified or compliant
No ISO, SOC, eIDAS, or similar certification has been obtained. No regulatory approval has been granted. Standards-informed engineering is not the same as certification.
ANANKE Sign is not a public product
Internal signing capabilities support Trust and T-CODE. ANANKE does not currently offer ANANKE Sign as a standalone electronic-signature service or make qualification claims.
Tamper-evident, not tamper-proof
ANANKE detects tampering through cryptographic evidence — it does not physically prevent it. No platform can guarantee the integrity of documents or items once they leave the platform boundary.
ANANKE Trust and T-CODE are not qualified trust services
ANANKE Trust and T-CODE provide verifiable evidence and tamper-detection. They are not legally qualified electronic signatures and make no qualified trust service claims. ANANKE Sign is a separate product line, currently in development. Learn more about ANANKE Sign.
Questions about security or architecture?
We are happy to discuss our security design, key management approach, and audit infrastructure with your IT, legal, or compliance team.