Trustaige · Trust center

Security by architecture, not by promise.

Trustaige is built so an audit is short: no passwords or shared sign-in secrets stored for people, private keys that never reach our servers, a tamper-evident event log and per-tenant encryption.

Architecture

Four properties, set by how it's built.

They come from the design, not from settings an attacker could switch off.

No shared secrets for sign-in

Traditional authentication stores passwords or tokens on the server — creating a target. For the people who sign in, Trustaige stores only public keys. Private keys stay with the user — on their device, in a hardware key, or in their platform’s passkey store — and never reach our servers. Your policy can require them to be bound to device hardware. A full server breach exposes public keys, which cannot authenticate anything. Where an integration does need a secret, such as an application’s client secret or a provisioning token, it is encrypted per tenant (see 04), and applications can prove themselves with signed keys instead.

Phishing-resistant by protocol, not by training

Credentials are bound to the origin (domain) where they were created. A passkey created for Trustaige will never respond to a challenge from a look-alike domain — the browser enforces this at the protocol level. There is no user judgment in the loop and no awareness training to depend on.

Biometrics stay on the device

Biometric verification happens locally to unlock the user’s private credential. Fingerprints, face templates, voice prints — none of it reaches Trustaige servers. Data we don’t hold can’t be lost, and customers take on no biometric-database obligations by deploying us.

Per-tenant encryption with integrity verification

Each organization’s secrets are encrypted with a unique key derived for that tenant. A breach affecting one tenant’s key material cannot decrypt another tenant’s data. Every secret is checksummed before encryption and verified on decryption — tampering at rest is caught on read, before the data reaches an application.

Standards we implement

Built on open standards. Auditable by anyone.

Every layer of Trustaige speaks an open, published standard. If you ever decide to leave, the same standards work in your new home.

FIDO2 / WebAuthn

W3C & FIDO Alliance

Passkey sign-in; credentials bound to the site that created them.

OpenID Connect

OpenID Foundation

Modern OAuth-based single sign-on for web and mobile apps.

SAML 2.0

OASIS Standard

Enterprise SSO for the apps your customers already federate with.

SCIM 2.0

IETF RFC 7643 / 7644

Inbound directory sync and outbound provisioning.

OAuth 2.0 + PKCE

IETF RFC 6749 / 7636

Authorization code flow with proof-key for code exchange.

OAuth 2.0 Device Authorization

IETF RFC 8628

Device flow for CLIs and input-constrained apps.

OAuth 2.0 Token Introspection & Revocation

IETF RFC 7662 / 7009

Apps check a token is still live, and revoke it the moment access ends.

OAuth 2.0 Token Exchange & JWT Bearer Grant

IETF RFC 8693 / 7523

Tokens exchanged across trust domains, and signed assertions redeemed for access, for AI agents and Apple Platform SSO.

Identity Assertion Authorization Grant (ID-JAG)

IETF OAuth working group Internet-Draft

Enterprise-managed access for MCP servers and AI agents, under the organization's policy. Implemented while the draft is in progress.

MCP authorization

Model Context Protocol specification

How AI clients discover, register with and get approval for MCP servers, including enterprise-managed authorization.

OAuth 2.0 DPoP

IETF RFC 9449

Tokens bound to a key the client holds, so a copied token is useless to anyone else.

Protected Resource Metadata & Resource Indicators

IETF RFC 9728 / 8707

MCP servers announce how to reach them, and every token names the one server it is for.

Authorization Server Metadata & OpenID Connect Discovery

IETF RFC 8414 · OpenID Foundation

Apps configure themselves from one published document instead of hand-copied settings.

Dynamic Client Registration & Client ID Metadata Documents

IETF RFC 7591 / 7592 + Internet-Draft

AI clients and apps register themselves, or identify themselves by a URL they control.

Client authentication with signed keys

IETF RFC 7523 (private_key_jwt)

Applications prove who they are with a key they hold, instead of a shared client secret.

OpenID Connect Back-Channel Logout

OpenID Foundation

Signing out in one place ends the session in every app that listens.

Shared Signals Framework & CAEP

OpenID Foundation

Real-time security events — revoked sessions, changed credentials — shared with the apps that act on them.

OpenID for Verifiable Credentials, SD-JWT VC & mdoc

OpenID Foundation · IETF Internet-Draft · ISO/IEC 18013-5

Issue and verify credentials your customers carry in their own wallets.

Privacy Pass

IETF RFC 9576–9578

HumanProof: prove a visitor is a person with a single-use token that can't be linked back to them.

ACME with device attestation

IETF RFC 8555 + draft

Device certificates issued only to hardware that proves what it is.

OMA-DM & MS-MDE2

Open Mobile Alliance · Microsoft Open Specifications

Windows enrollment and device management through Windows' built-in management client.

CEF, LEEF, OCSF v1.3

ArcSight · IBM QRadar · OCSF Project

Audit export formats — the same shapes your SOC and auditor already read.

Certifications & compliance

Independently audited. Accountable under Nigerian law.

Our workforce platform is certified to ISO/IEC 27001:2022, and we comply with the Nigeria Data Protection Act 2023. Certificate available on request.

ISO/IEC 27001:2022
NDPA 2023

Data protection

What we hold about people, and what they can ask of us.

Nigeria Data Protection Act 2023

Trustaige Limited is the data controller for the personal data described in our privacy policy. We have a designated Data Protection Officer and process personal data under documented lawful bases.

Access and erasure

People can ask what we hold about them and ask us to erase it. An erasure redacts personal fields from the audit log with a receipt in their place, so the log’s hash chain still verifies.

Data-processing addendum

Customers can request a data-processing addendum that sets out how we process personal data on their behalf.

Coordinated disclosure

Found something? Tell us.

If you’ve identified a security issue in Trustaige, we want to hear about it. We acknowledge reports within one business day, give you a public credit when the issue is fixed, and don’t take legal action against good-faith research.

security@trustaige.com

Our policy

Acknowledgement within 24 business hours.
Initial assessment within 5 business days, with a triage status.
Coordinated disclosure window: 90 days from acknowledgement, extendable by mutual agreement.
Public credit (or anonymity, your call) once a fix is released.
We don’t pursue legal action against good-faith security research conducted under this policy.

Start a conversation

If your auth layer is on the agenda, so are we.

We'll walk through a working deployment, map it to your stack, and tell you where Trustaige fits — and where it doesn't.

Talk to us Or see pricing

Nigeria

Trustaige Limited
Spacepad Building, KM 18 Lekki-Epe Expressway
Lagos, Nigeria

United States

Registered office
131 Continental Dr, Suite 305
Newark, DE 19713

Direct

shield@trustaige.com
+234 816 381 6789

Security

Coordinated disclosure
security@trustaige.com