Mobile app security
ShieldCert issues a unique mTLS certificate per device. Your backend only completes the handshake with your real app: a bot or a repackaged app never reaches the login endpoint, even with valid credentials. No CAPTCHA, and before 2FA.
1 in 4
logins analysed was a credential stuffing attack.
Okta, The State of Secure Identity Report 2023A bot that reaches your form can trigger real OTP text messages. That is the fraud the industry calls SMS pumping, or artificially inflated traffic, and you are the one paying for it.
Twilio, What is SMS Pumping FraudA second factor only kicks in once the password has been validated — by then the attacker already knows which credentials work. ShieldCert drops the connection during the TLS handshake, before your application ever sees the request.
Cryptographic per-device identity, enforced at the edge of your own infrastructure.
Stops bots and repackaged apps from trying username and password combinations against your login API, before 2FA is even involved.
Credential stuffing traffic never completes the handshake, so it burns neither your backend cycles nor your verification text messages.
Every registered install gets its own certificate, proving the app is genuine and has not been tampered with.
Works with your backend as it stands: you configure Nginx to require a client certificate on the sensitive endpoints.
Mutual authentication between app and backend with no CAPTCHA, no extra steps and no change to your sign-in flow.
Short-lived certificates that rotate on their own. An agent in your own infrastructure reads the syslog, detects whether a certificate has been compromised and reports it so it gets blocked, with no manual step.
You integrate the SDK into your mobile app and require mTLS on your backend. From there, the flow is this:
The questions a security team asks before putting this into production.
A CAPTCHA and a WAF decide after the fact, on statistical signals: IP reputation, client fingerprint, request rate. An attacker with residential proxies and a well-configured client walks past those filters, and the one paying the friction cost is your legitimate user. mTLS does not score or estimate: either the client presents a certificate issued for that device and signed by your CA chain, or the TLS handshake never completes. The rejection happens at the transport layer, before your application sees the request, and there is nothing for the user to solve.
The SDK is native and covers the two main platforms: Android and iOS. Hybrid frameworks (React Native, Flutter and Capacitor) are not supported yet: we are investigating how to support them and there is no committed date, so we would rather say so before you integrate anything. If your app is hybrid, tell us when you request beta access — it helps us decide which one to tackle first.
It helps to separate the two checks. Chain-of-trust validation is done by your own Nginx against your CA, without leaving your infrastructure. The revocation check is online: Nginx is configured with ssl_ocsp on and queries the OCSP responder. To bound that coupling, OCSP responses are cached for one minute, which cuts query volume and absorbs a short responder interruption. An outage longer than that window does affect new handshakes: that is the price of verifying revocation online rather than trusting a certificate until it expires, and it is a trade-off we would rather explain than hide.
There are two routes. The manual one: you mark the device certificate as revoked from the dashboard, the OCSP responder stops vouching for it, and the next validation on your backend rejects it; with the one-minute OCSP cache, propagation takes at most that window. The automatic one: an agent deployed in your own infrastructure reads the syslog, determines whether a certificate has been compromised and reports it so that it gets blocked, without anyone having to watch a dashboard. Certificates are also short-lived and rotate on their own, which bounds the window of a leaked certificate even if nobody revokes it by hand.
We are in closed beta. Instead of customer logos we cannot name yet, here is what you can verify for yourself:
Access is granted case by case so we can support each integration. There is no anonymous waiting list.
The integration reference is public and readable before you request access, with no sales call in between.
It is your Nginx that requires the certificate and validates it against your CA chain. The revocation check queries the OCSP responder, with responses cached for one minute.
Underneath it is mutual TLS, which your stack already understands. If you leave tomorrow, the authentication mechanism is still a standard one.
Leave us your email and we will give you access to the closed beta and the integration documentation.
Prefer email? Write to [email protected]