developersmobilesecurity

Automating Proof-of-Presence: Using Device and Messaging Signals to Prove a Signer’s In-Person Status

UUnknown

2026-02-16

10 min read

Combine RCS presence, device attestation and OS signals to build tamper-evident proof-of-presence for in-person signatures.

Hook: Stop wondering whether a signature was truly in-person

When your legal, compliance, or operational teams demand an auditable, tamper-evident record that a signer was physically present, simple IP logs or an emailed PDF won't cut it. Today’s technology professionals need patterns that combine cryptographic device attestation, live messaging presence, and OS signals to produce strong proof-of-presence and reduce repudiation risk—without sacrificing user experience. This article provides concrete, implementable patterns (with API/SDK primitives and sequence flows) you can integrate in 2026 to harden signatures where physical presence matters.

Why proof-of-presence matters now (2026 context)

Late 2025 and early 2026 accelerated two trends: wider carrier and vendor support for RCS with end-to-end encryption, and more robust OS-level attestation APIs across mobile and desktop platforms. Regulators and courts continue to value auditability and chain-of-custody for evidence; sectors such as finance, healthcare, and government increasingly require demonstrable physical presence for high-risk transactions.

At the same time, operational reliability (OS update rollouts, device firmware issues) affects attestation trust. Recent vendor advisories about update-related failures in client OSes underscore the need to record patch/health state as part of attestation evidence.

What signals to combine

Use a multi-signal approach. No single signal is sufficient—combine them to raise the cost of spoofing and provide layered non-repudiation.

RCS presence: delivery, read receipt, typing/presence indicators and (with modern rollouts) E2EE-secured messaging channels allow you to deliver cryptographic challenges to the signer’s messaging client.
Device attestation: hardware-backed attestation (TPM/SE/TEE / Apple Secure Enclave / Android StrongBox) proves the signer’s app runs on an untampered device and can sign a challenge with keys bound to that device.
OS signals: build/version, patch level, secure boot/verified boot status, and attestation of biometric unlock events or app-verified user gestures.
Proximity signals: short-range radio (Bluetooth LE ephemeral beacons), NFC tap evidence, or Wi‑Fi SSID scans tie a device to a physical location at a specific time.
Time and timestamping: secure time sources or a trusted timestamp authority (TSA) to prevent replay and preserve chronology.

Threat model and guarantees

Define the attacker capabilities you want to mitigate. Here are common threats and the guarantees layered signals provide:

Spoofed identity: mitigated by device attestation that binds a key to a hardware security module.
Replay of earlier approvals: mitigated by single-use, server-issued cryptographic challenges and secure timestamps.
Man-in-the-middle on messaging: mitigated by RCS E2EE and challenge-response signatures.
Compromised app or OS: mitigated only partially—record attestation statements about secure boot and patch level; require elevated assurance (e.g., hardware-backed keys, biometric confirmation).

Three practical technical patterns

Below are three patterns ranked by assurance and engineering effort. Each pattern includes the key artifacts you should store for audit and verification.

Pattern A — Messaging Challenge + Device Attestation (moderate assurance)

Best when you want frictionless UX and rely on the signer’s messaging client being tied to the device.

Server creates challenge (nonce + doc hash + expiresAt) and records it with the document ID.
Server sends the challenge via RCS message to the signer’s validated phone number. Use E2EE-enabled RCS where available.
User’s app receives the challenge and calls the device attestation API to produce an attestation token and a challenge signature made by a device-bound key.
App posts {challengeSignature, attestationToken, deviceState, proxSignals} to the server over TLS.
Server validates the attestation token (signature chain, certificate path, freshness), verifies the challenge signature, then signs and seals the document along with the attestation bundle.
Server issues a timestamp (TSA) and stores an immutable evidence bundle: {documentHash, sealedSignature, attestationToken, rcsDeliveryReceipt, timestamp}.

Evidence to store: RCS delivery/read receipts, attestation tokens, challenge signature, server seal, TSA timestamp, deviceState report.

Pattern B — Proximity + Short-range + Device Attestation (high assurance for in-room presence)

Use where physical presence within a room or at a kiosk is required (e.g., notary office).

Kiosk/server broadcasts a short-range ephemeral beacon (Bluetooth LE advertisement or NFC challenge token).
User taps or pairs; the app reads the beacon and issues a device attest-signed response binding beaconID, documentHash, and timestamp.
Simultaneously, the app collects local signals: Wi‑Fi SSID fingerprint, BLE RSSI, and a short video/photo hash if policy allows.
App sends the bundle + attestation to server; server verifies attestation and correlates beacon logs (server-side) to confirm physical proximity at the time of signing.
Server seals the document and stores the proof bundle including beacon logs and attestation.

Evidence to store: ephemeral beacon record (server-side), attestation token, proximity metrics (RSSI), sealed document, and TSA timestamp.

Pattern C — Multi-factor Presence: RCS channel + Biometric Affirmation + Device Attestation (very high assurance)

For the highest assurance where repudiation risk is critical (e.g., high-value financial agreements).

Server sends RCS challenge to device.
User opens the app, the app triggers platform biometric unlocking (with user consent) and signs the challenge using a hardware-bound key.
Attestation API returns a token asserting secure biometric authentication occurred during signing.
App submits {biometricAssertion, attestation, rcsDeliveryReceipt, location/proximity} to server.
Server validates everything, applies its seal, and emits a non-repudiation report formatted for legal review.

Evidence to store: biometric assertion metadata (not raw biometrics), attestation tokens, RCS receipts, sealed signature, timestamp, and audit logs.

API / SDK integration primitives (developer checklist)

These are the common primitives you should expect in any modern SDK or attestation API and how to use them in your flows.

challengeCreate(documentHash, ttl) — Server: creates single-use challenge token
sendRcsMessage(msisdn, payload) — Server: sends challenge via RCS with delivery/read receipts when available
attestSign(challenge) — Client SDK: uses platform attestation to sign challenge with device-bound key and returns attestation token
verifyAttestation(token) — Server: validate chain, certificate, and claims (deviceState, secureBoot, patchLevel)
sealDocument(docId, evidence) — Server: creates a cryptographic seal (server key or HSM) and records an evidence bundle
timestamp(hash) — Server/TSA: add a trusted timestamp to prevent backdating

Practical verification pseudocode

// Server-side verification flow (pseudocode)
receiveSubmission(submission) {
  if (!validateChallenge(submission.challenge)) reject();
  if (!verifyAttestationToken(submission.attestationToken)) reject();
  if (!verifySignature(submission.challengeSignature, submission.attestationToken.publicKey)) reject();
  if (!validateProximity(submission.proxSignals)) logWarning();
  tsaStamp = requestTimestamp(submission.documentHash);
  sealed = sealWithHSM(submission.documentHash, tsaStamp, submission.attestationToken);
  storeEvidenceBundle(submission, tsaStamp, sealed);
  return sealedReceipt(sealed);
}

Attestation APIs: platform-specific guidance (2026 notes)

In 2026, platform vendors continue to standardize attestation primitives. Expect the following:

Android: Use hardware-backed Key Attestation via Android Keystore and Play Integrity/Device Configuration APIs. Prefer StrongBox-backed keys and attestations that include verified boot and app hash claims. Keep an eye on Google’s device integrity updates and new attestation formats rolled out through late 2025.
iOS: Use App Attest / DeviceCheck-like services and Keychain-backed keys. Apple has incrementally improved attestation and has been participating in RCS E2EE rollouts—leverage platform-signed attestation statements where available.
Windows: TPM-based attestation and Windows Hello assertions are available on modern devices; be aware of OS update and shutdown reliability notices that can affect attestation consistency—capture OS build and patch metadata in the attestation claims.
Cross-platform: Use standards-based formats (COSE / CWT / JWT with attestation extensions) and validate certificate chains against vendor-endorsed roots.

Storing and sealing evidence: design patterns

Your proof is only as strong as your preservation. Follow these patterns:

Immutable evidence bundle: store documentHash, challenge, attestationToken, signatures, RCS receipts, proxSignals, TSA stamp in a single bundle signed by an HSM-protected server key.
Content addressing: use content hashes (SHA‑256/512) and a logical manifest that maps artifacts to timestamps.
WORM or append-only storage: write-once or append-only storage reduces risk of tampering. Consider notarization with distributed anchors (e.g., anchoring bundle hashes on a public ledger as an additional tamper-evident checkpoint).
Audit logs: include operational metadata: operator IDs, API request IDs, device IPs, and verification results.

Verification for auditors and courts

Provide a human- and machine-readable verification report that contains:

Document hash and server seal
Challenge and response timestamps
Attestation token (with description of claims: secure boot, key type, key-hash)
Channel receipts (RCS delivery/read receipts signed by carrier/gateway if possible)
Proximity evidence: beacon logs, RSSI values, Wi‑Fi SSID fingerprints
TSA timestamp and verification path
Machine verification steps and expected validation checks

Provide a compact cryptographic assertion for automated checking and an expanded human-readable bundle for legal review.

Operational considerations — privacy, retention, and UX

Balancing privacy and evidentiary value is critical.

Minimize PII in attestations: store only hashes or derived identifiers; retain raw location or biometric data only with explicit consent and for the minimum retention window required by policy or law.
Retention policy: align with regulatory retention e.g., finance or healthcare. Ensure secure archival and ability to produce evidence years later.
Consent and transparency: present clear UX for why the app will collect proximity and attestation signals and provide revocation paths for lost devices.
Resilience to OS updates: implement version checks and anomaly flags when platform advisories (e.g., update-related shutdown warnings) indicate instability that could affect attestation claims. Consider common device lifecycle issues highlighted in buyer and device reliability guidance.

Advanced strategies and future trends (2026 and beyond)

Plan for the near future:

RCS E2EE becoming ubiquitous: carriers and vendors moved RCS E2EE forward in 2025; by 2026 expect RCS to be a reliable challenge channel in many markets. Use RCS delivery/read receipts as cryptographically corroborated signals where the operator offers signed receipts.
Federated attestations: devices may offer attestation statements endorsed by multiple vendors (e.g., carrier + OEM + OS) improving chain-of-trust.
Federated identity integration: tie attestation flows to identity proofing systems (credential wallets, eID schemes) for stronger legal binding.
ML anomaly detection: augment proof bundles with behavioral signals and ML-based anomaly scoring for additional risk signals at verification time.

Checklist for engineering teams

Before you start implementation, confirm:

You can send and verify RCS messages reliably for targeted geographies.
Your chosen attestation APIs support hardware-backed keys and provide cryptographic tokens you can validate server-side.
Your sealing process uses an HSM or KMS for key security and integrates with a TSA for trusted timestamps.
You have a retention and data minimization policy agreed with legal/compliance stakeholders.
There is a verification UI and API to produce court-ready evidence bundles.

Example end-to-end flow (concise)

Sequence summary for Pattern A:

Server: createChallenge(docHash) -> challenge
Server: sendRcsMessage(userNumber, challenge)
Client: attestSign(challenge) -> {sig, attToken, deviceState}
Server: verifyAttestation(attToken) && verifySignature(sig)
Server: sealDocument(docHash, attToken, rcsReceipt) + tsaTimestamp

Final notes: legal admissibility and risk alignment

No technical design removes legal judgment. The goal is to provide strong, auditable evidence that materially increases the cost for an attacker to repudiate a signature. Work with legal counsel and local regulators to map technical assurance levels to legal acceptability in your jurisdiction. Keep evidence exports in standards-based formats so that independent experts can validate the chain-of-custody years later.

Call to action

Ready to prototype? Start with a lightweight Pattern A implementation: leverage an RCS gateway that supports delivery receipts, integrate your mobile SDK with platform attestation APIs, and build an immutable evidence bundle signed by an HSM. If you want a 6-week integration plan, sample SDK code, and an audit-ready evidence template, contact our integration team at sealed.info to get a tailored implementation blueprint for your systems.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.