> For the complete documentation index, see [llms.txt](https://legacy-docs.usesmileid.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://legacy-docs.usesmileid.com/further-reading/security-overview.md). # Security Overview SmileID is committed to keeping your data and your users' data safe and secure. We have implemented and continue to implement many different approaches and options to ensure security. If you do have any immediate security concerns then please contact us immediately. *** ## Certifications Smile ID sets the standard in data protection and biometric security in Africa. We prioritise delivering exceptional quality and robust security for our customers. We safeguard your data and protect your business from fraud by adhering to the highest industry standards. Our commitment is demonstrated through multiple compliance certifications across African countries and the attainment of ISO 30107-1:2016, ISO 30107-3:2023 Level 2, ISO 27001, and SOC 2 Type II certifications.

ISO30107:2023 Certified

ISO30107:2016 Certified

ISO27001 Certified

SOC2 Type II Certified

*** ## API Keys Smile allows customers to create and manage multiple API keys to cover their needs. API keys are environment specific (an API key for the Sandbox environment will not work in the Live environment, and vice versa). We encourage customers to rotate their API keys on a regular basis, every 90 days or more frequently is best practice. We also encourage customers to use different API keys for different integration methods with SmileID. i.e. to maintain one or more keys for their mobile integration, and using separate keys for any server-to-server integration. This allows customers to rotate keys independently, based on their need, without disruption to other integrations. *** ## Smile Callbacks For asynchronous job requests, Smile will send a Callback response to the specified customer URL ### IP Allowlisting Callback requests will come from one of the following IP addresses for Production callbacks: * `13.51.0.119` * `34.240.137.52` * `51.20.27.3` * `52.213.46.74` Callback requests will come from one of the following IP addresses for Sandbox callbacks: * `13.48.228.158` * `16.170.104.93` * `54.246.37.255` * `99.81.237.141` We would urge customers to only allow requests to their callback URL from these IPs to help ensure the request originates from SmileID. If your receiving service will process Callbacks from both Production and Sandbox, you should allowlist all of the specified IPs. ### Callback Signing The callback request body will contain a signature and timestamp, generated using the API key used in the originating job, that customers can verify to ensure the callback request is valid. ## Mobile Security Our platform runs multiple checks on every verification, and using our mobile SDKs unlocks even richer insights. Based on the results, we'll either block a suspicious verification outright or surface a warning so your team can take action. ### Why Debug Builds Fail Play Integrity Checks If you test with an Android debug build, our fraud integrity checks will flag the request. You will get an error that indicates the device is suspicious (`0817 - Approved with Attention - Suspicious Device Detected`). This happens because debug builds are signed with a debug key, not your Play/release signing key. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://legacy-docs.usesmileid.com/further-reading/security-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.