Attestation SDKs for iOS/Android
What device attestation verifies, the fraud scenarios it addresses, and how Cipherstep’s end-to-end attestation fits into your app and backend.
What attestation is
Device attestation gives your backend evidence about the environment making a request. Is the device consistent with the system it claims to run? Is your application executing in an ordinary runtime, or is another tool changing what it sees and does? Those questions matter because a valid-looking request can come from a manipulated client.
Cipherstep’s SDK collects device and firmware-related values, environmental behavior, and app runtime observations. Semantic seals and encryption package those observations into an opaque envelope for server-side analysis. The application carries that envelope; it does not need to read or interpret the checks inside it.
Attestation helps assess whether a device and runtime are suitable for a protected action. It supplies integrity evidence alongside your authentication, identity verification, and transaction controls; it does not establish a person’s identity by itself.
The problems it solves
Sophisticated fraud often targets an application’s trust layer: the login, identity capture, account recovery, or suspicious-activity challenge that decides who can proceed. An attacker who controls the runtime can try to substitute camera input, alter a check, or automate a flow while preserving the appearance of a normal session.
If that manipulation goes unrecognized, the next system may treat the result as trustworthy. An account opened with a stolen identity can become a route for laundering funds. A compromised login can give an attacker access to a real customer’s account. Downstream controls may still identify the abuse, but by then the attacker has crossed an important boundary.
Cipherstep adds a check on the client behind those flows. Signals of instrumentation, runtime hooks, or inconsistent device identity can inform a challenge, review, or block before the protected action proceeds. Your backend combines the result with the account and business context it already owns.
How Cipherstep integrates with your system
The SDK sits inside your application as an iOS XCFramework or Android AAR. Trigger a fresh collection for the action you want to protect, then attach the resulting opaque envelope to the request you send to your backend. Collection is asynchronous on iOS; Android exposes a collection call that runs off the UI thread. The exact entry point is documented with your SDK release.
Your backend submits the evidence to the Decision API and retrieves the completed evaluation. The response includes a recommended action—allow, review, challenge, or block—and high-level signal diagnoses with confidence values. Evaluation is asynchronous: an accepted submission is not an allow decision.
For example, real phones in a coordinated operation can still carry instrumentation or disagreeing device observations. The response below shows the kind of findings your team can review. Your backend uses the returned decision to apply its policy and route the end user.
JSON excerpt{
"status": "complete",
"analysis": {
"decision": "block",
"signals": [
{
"type": "device_identity_inconsistent",
"confidence": 100
},
{
"type": "dynamic_instrumentation_detected",
"confidence": 90
},
{
"type": "runtime_hooking_detected",
"confidence": 95
}
]
}
}Secure SDK releases and audit controls
The Developer Portal gives your team a controlled source for its SDK releases. Review platform and release status, verify an artifact’s SHA-256, and download the appropriate build. Audit records make SDK downloads and access-related changes traceable, so the team responsible for shipping the app can follow how releases are obtained and used.
Client security has to evolve with the people trying to bypass it. Cipherstep varies protection mechanisms across customer builds and SDK releases, including the representation and sealing of collected evidence. Understanding one build should not give an adversary a reusable map of every customer’s SDK or the next release. They must re-examine the changed surface and revalidate their tooling.
A release policy makes that ongoing research part of your application’s defenses. Validate new SDKs, ship them with app updates, and monitor adoption rather than leaving an old build in circulation indefinitely. Obfuscation, semantic protections, encryption, and release variation add layers of friction; consistent updates keep those layers changing as attackers adapt.