> Toden documentation. For the full index fetch /llms.txt. Every page is available as Markdown by appending .md to its URL. Identity verification uses /api/kyc, Risk Intelligence uses /api/v1; they are separate contracts with different error shapes. Never invent an endpoint, field or enum value: read the API reference page for the operation first. # Security and compliance > How Toden protects customer and applicant data: API key scopes, signed webhooks, field encryption, access control, audit logs, and a plain statement of our certification position. This page is for the developer or compliance lead running a security review. It lists the controls that exist in the product today, states our certification position plainly, and says which documents you can request. > **Note** > > The public version of this information is the [Trust Centre](https://toden.co/security) on the Toden website. If the two ever differ, the Trust Centre is the approved wording. ## Certification position Toden is **not certified yet**. Specifically: | Item | Status | | ----------------------------------- | -------------------------------------------------------------------------------------------------------- | | SOC 2 | Not held | | ISO 27001 | Not held. We build to the control areas the standard describes, which is alignment and not certification | | iBeta testing of liveness checks | Not done | | Independent penetration test report | No completed report to share | Each report will be listed on the Trust Centre when it exists. Do not rely on any statement of certification that does not appear there. ## Frameworks we align to "Aligned" means the product and our policies follow the framework. It is not a certification or a regulator's approval. | Area | Framework or standard | | -------------------- | -------------------------------------------------------------------------------------------- | | Data protection | Nigeria Data Protection Act 2023 (NDPA), EU GDPR, UK GDPR | | Financial crime | FATF standard, sanctions screening against UN, OFAC, EU and UK lists | | Regulatory reporting | Suspicious activity and transaction reports produced in the goAML structure, with XML export | | Identity documents | ICAO 9303, the electronic passport standard | | Encryption | AES-256 for stored sensitive fields | | Information security | ISO 27001 control areas (aligned, not certified) | ## API keys Every key has a scope and an environment. See [Authentication](/get-started/authentication) for the full reference. * **Publishable keys** (`pk_…`) ship in your client. They can start a verification and read a minimal status. They cannot read results, personal data or captured media. * **Secret keys** (`sk_…`) stay on your backend. Only a secret key can read full results and media. * **Key restrictions.** Lock a publishable key to your own web origins, and a secret key to your own IP addresses or CIDR ranges. A request from anywhere else is refused with `403`. An empty list means the key is unrestricted. Manage this in [API keys](/get-started/console/api-keys). * **Hashed storage.** Keys are stored as hashes. A secret key is shown once, when you create it, and cannot be retrieved afterwards. Publishable keys are public by design and can be viewed again. * **Revocation** takes effect on the next request. Passwords, session tokens and invite tokens are also stored as hashes only. ## Webhook signatures Every webhook is signed with HMAC-SHA256 using the secret assigned to that endpoint, so you can check a delivery came from Toden before you act on it. * Verify the `X-Myaza-Signature-V2` header against the raw request bytes. * Reject a signature whose timestamp falls outside the replay window in `X-Myaza-Replay-Window`. * Compare signatures in constant time. * During a secret rotation the header carries more than one candidate, so no delivery is lost. The endpoint secret is shown once at creation. The algorithm and code samples are in [Webhook signatures](/integrate/webhooks/signatures). ## Data handling #### Biometrics are captured in the SDK Selfies, liveness video and document images are captured in the SDK and uploaded straight to Toden. Your servers do not need to handle raw biometrics. Your backend receives the result, and media only if it asks with a secret key. Uploads that are never submitted expire and are deleted. Revoking a biometric enrolment deletes the stored face template. #### Sensitive fields are encrypted at rest ID numbers, phone numbers, record photos and two-factor secrets are encrypted in the application with AES-256-GCM before they are stored. Search uses a one-way hash, so the plaintext value is never queried directly. Personal data is also encrypted in transit. #### Deletion is soft, with restore through support Deleting a verification or a customer record removes it from every surface you can read, in the console and the API. Toden keeps the record marked as deleted, so a compliance history cannot be silently rewritten. A deleted record cannot be restored through the API. If something was deleted by mistake, contact support. See [Manage records](/user-verification/server-api/manage-records) and [Data retention](/get-started/console/data-retention). #### Sandbox is isolated from production Each key belongs to one environment, and a key used against the wrong environment is refused. A sandbox key cannot read production results or media. Sandbox keys accept published test IDs only and are never charged. Production access requires an approved business review. See [Environments](/get-started/environments) and [Sandbox testing](/get-started/sandbox-testing). ## Console access | Control | What it does | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Two-factor authentication | Authenticator-app codes with single-use recovery codes. An organisation can require it for every member | | Passkeys | Sign in to the console with a passkey | | Session revocation | Any session can be revoked at once. Changing a password signs out every device | | Roles and permissions | Define your own roles and grant permissions action by action. See [Roles and permissions](/get-started/console/roles-permissions) | | Audit log | Every administrative change is recorded with who made it and when. See [Audit logs](/get-started/console/audit-logs) | | Identity event chain | Identity events are hash-chained, so an altered record can be detected | | Four-eyes report filing | The person who drafts a suspicious activity report cannot be the one who files it | ## Privacy and legal documents | Document | Where to get it | | ------------------------------------------------ | ---------------------------------------------------------------------------- | | [Privacy policy](https://toden.co/legal/privacy) | Published | | [Terms of use](https://toden.co/legal/terms) | Published | | Reliability record | Published. See [Status and reliability](/get-started/status-and-reliability) | | Data processing agreement | On request | | Current sub-processor list | On request from [privacy@toden.co](mailto:privacy@toden.co) | Toden uses sub-processors, for example cloud infrastructure providers, and requires each one to give equivalent data protection and to process personal data only on our documented instructions. Where personal data is transferred outside Nigeria, the transfer relies on a mechanism the NDPA permits, such as contractual safeguards. Toden does not sell personal data. If a personal data breach is likely to put people at risk, Toden notifies the Nigeria Data Protection Commission without undue delay and, where feasible, within 72 hours of becoming aware of it, and informs affected customers and data subjects where the NDPA requires it. Privacy questions and data subject requests go to the Data Protection Officer at [privacy@toden.co](mailto:privacy@toden.co). ## Status and reliability Live service status, incidents and scheduled maintenance are on the [status page](https://status.toden.co). Measured availability is published as a reliability record that you can share with your own reviewers. These are observed figures and are not a service level agreement. See [Status and reliability](/get-started/status-and-reliability). ## Report a security issue Toden publishes a `security.txt` file at `https://toden.co/.well-known/security.txt`. To report a vulnerability, email [hello@toden.co](mailto:hello@toden.co) or use the [contact page](https://toden.co/contact). Include the steps to reproduce and the affected URL or endpoint. Please do not include real personal data in a report. If you suspect unauthorised use of your own Toden account, tell us promptly at [security@toden.co](mailto:security@toden.co), and revoke the affected keys and sessions in the console. #### [Authentication](/get-started/authentication) Key types, scopes and error codes. #### [Webhook signatures](/integrate/webhooks/signatures) Verify V2 signatures and reject replays.