Mobile app for electronic signature: where the process breaks
Signing documents from a phone breaks not on the "Sign" button, but at the junction of the session, the key, and the communication channel.
The client taps confirm, the app goes to the background, and a minute later returns to the login screen — and the signature they already considered applied does not exist either on the server or in the container.
The second most frequent failure is the crypto container on the device: the key is bound to a specific platform's storage, and after a system update, a device change, or an app reinstall it becomes unavailable, and along with it access to signing is lost.
A mobile electronic signature is sensitive to exactly where the key lives. If it is in the platform's secure storage, the app must correctly handle access revocation, biometric lockout, and a change of device owner.
If the key is moved to an external medium or to the cloud, a network call is added, and offline signing stops working altogether.
A separate category of failures is incompatibility with the key store: the crypto provider built into the app does not see the certificate because it resides in the system store under a different profile.
A weak connection finishes off the process where everything else is configured. The document is signed in seconds, but sending the result to the verification server can take minutes, and without a local queue with retries the user sees "error" on a fully valid signature.
Worse is when the app blocks the interface during the network call: the person leaves the screen, the session expires, and a retry requires reassembling the document package.
The cost of each such failure is not a lost minute but a derailed process: the contract is not signed on time, the client calls support, and the service team deals with logs instead of new onboardings.
Let's break down how this is closed at the level of app architecture, key handling, and offline mode.
What a proper signing architecture delivers and operating modes
Signing modes: what we choose and why
The signing mode determines where the cryptographic signature is generated and what happens when the connection drops. In cloud mode, the key lives on the service side, and the app only initiates the operation — the signature reaches completion even if the network is lost midway.
In local mode, the key stays on the device, and the entire process runs without external calls. In practice, a hybrid is chosen: sensitive operations — locally, high-volume — through the service.
Key storage and hardware crypto module
A key sitting in an app's ordinary storage is the main source of failures and incidents. The device's hardware crypto module keeps the key out of reach of the code: signing is performed inside a secure perimeter, and only the result comes out.
This eliminates an entire class of problems — compromise when the device is lost, key extraction from a backup, substitution during reinstallation.
What delivers a measurable effect
- The share of successful signings grows through retries at the protocol level, not the user level.
- Time to a finished document shrinks: preparation, signing, and sending happen in a single operation.
- The "signature not generated" failure class disappears — the operation either completes or rolls back entirely.
| Option | When it fits | Limitations |
|---|---|---|
| Cloud mode | High-volume operations, low-end devices | Dependence on the communication channel |
| Local mode | Sensitive documents, offline | Requires a hardware module |
| Hybrid | Mixed scenarios | More complex configuration and support |
Our engineers build the signing scheme on the device's hardware crypto module, so the key never leaves the secure perimeter, and the app stays responsive even on a weak channel.
Development stages: from document workflow audit to handover
Development of a mobile application for electronic signature begins not with the interface, but with an audit of the document workflow: which types of documents are signed, who initiates the signature, where the originals are stored, which certification authorities are already in use.
At this stage we fix the trust scheme — who issues certificates, how their status is verified, what happens upon revocation. A mistake here is the most costly: reworking the cryptographic core after release means re-certification and re-issuance of keys for all users.
Further work proceeds in stages, where each subsequent one relies on the result of the previous one.
- Document workflow audit — we analyze real signing scenarios, participant roles, document formats, and regulatory requirements. The output is a process map and a list of integrations.
- Trust scheme design — we determine where keys are stored, how authentication is structured, which events are recorded in the log. We separately describe the behavior in the event of key compromise.
- Cryptography setup — we connect the crypto provider, implement signature generation and verification, and handle certificates and timestamps. We store keys in the device's secure storage, not in a regular file.
- Signature verification on real documents — we run the flow on actual contracts and acts, and compare the result against reference systems. We separately test failures: expired certificate, network loss, interrupted operation.
- Integration with accounting systems — we connect the application to the document storage and the customer's internal services, and configure logging and notifications.
- Solution handover and training — we hand over the source code, documentation, access to the build environment, conduct training for the customer's team, and provide support for the first releases.
The order of the stages is not accidental: cryptography is configured only after the trust scheme has been agreed upon, and verification on real documents takes place before integration — otherwise signature errors will surface already in the production environment.
Describe your signing scenario — we will get back to you with an estimate and a work plan by stages.
How does a cloud signature differ from a local one on a device?
The key difference is where the private key physically resides and who controls the signing operation.
In the cloud model, the key is stored on a secure server of the certification authority, and the mobile app for electronic signature acts as an interface: the user confirms the action, the request goes to the server, the signature is generated there and returned ready-made.
In the local model, the private key resides in the secure storage of the phone itself — a hardware module or an isolated area — and never leaves it.
Hence the main difference in the scenario of device loss. In the cloud model, the phone is essentially an access terminal: access is revoked by changing the password or revoking the session, while the key itself remains on the server and continues to work from another device.
With a local key, the phone is the signature carrier itself: without a backup copy of the key, it cannot be restored, which means all previously issued documents remain valid, but it is no longer possible to sign new ones with the same key. Backup here is a mandatory element, otherwise losing the device means losing the ability to sign.
Authenticity verification works differently. A cloud signature is verified through the certification authority's service: the verifier contacts it and receives confirmation that the certificate is valid and not revoked at the time of signing.
A local signature is verified autonomously — by the certificate and the chain of trust, without contacting a server, which is convenient in closed environments without constant network access.
Each model has its own limitations. The cloud one requires a constant communication channel at the moment of signing and trust in the operator that stores the key.
The local one does not depend on the network, but shifts responsibility for the safekeeping of the key to the device owner and scales worse to a team where several employees must sign with differentiated rights.
The choice of model is determined by what is more critical: the speed of revoking access when a device is lost or autonomy of operation without a network.
Case: Signing contracts in the field without a stable connection
Before implementation, a field engineer signed work completion certificates on site, and the finished document appeared in the system only after returning to the office.
With a weak signal, the app lost the session in the middle of signing, and the signature had to be started over — with a new confirmation code.
According to the support ticket log, such interruptions accounted for up to a third of all requests on the mobile track, and the share of documents signed on the first attempt held at around 60%.
We rebuilt the scenario around offline operation: the contract template, details, and signing certificate are cached on the device when heading into the field, and the signature itself is generated locally and queued for sending.
As soon as a connection appears — even briefly — the queue goes to the server and the document is assembled into a finished file with a timestamp.
The key decision: the signature is considered legally valid at the moment it is generated on the device, not at the moment of delivery, so a channel interruption no longer devalues the engineer's work.
What changed in the metrics
- The share of documents signed on the first attempt grew from 60% to 97% — repeat signings have almost completely disappeared.
- The time from pressing "sign" to the finished file in the system dropped from several hours (waiting to return to the office) to 2-4 minutes after a connection appears.
- Support requests about signing interruptions fell by more than fivefold — the load on the first line decreased, and engineers stopped calling from the site.
| What we checked | Before | After |
|---|---|---|
| First-attempt signature | ~60% | 97% |
| Time to finished document | hours | minutes |
| Support requests | baseline | −80% |
We also separately addressed version conflicts: if a document has changed on the server while the device was offline, the app does not silently overwrite it, but shows the discrepancy and offers to re-sign the current revision. This eliminated a class of errors where an outdated finished document ended up in the system.
We built the queue logic and conflict resolution on React Native with a native wrapper for working with the crypto provider — the cross-platform layer delivered identical behavior on both platforms without duplicating the signing code.
Compatibility, rollback, and access: what to discuss before the start
Before the start, the client usually has three questions in mind: how the application will fit into the current accounting system, what will happen if signing fails, and who will get access to the private keys. We answer each of them.
What if the accounting system does not support the required format?
We check compatibility with the accounting system at the design stage: we compare user, group, and permission models, determine how the application obtains a session token and where it writes the status of a signed document.
If the accounting system provides data through a software interface, we integrate directly; if only through an export, we build an intermediate synchronization layer so as not to change the core.
How are changes rolled back? We plan rollback in advance: every version of the application and data schema is labeled, migrations are reversible, and switching between builds takes minutes.
If a new version breaks the signing scenario, we return to the previous one without losing already signed documents.
Who can sign what? We describe access and roles with a matrix: who initiates signing, who confirms, who only reads. Signing policies define which documents require one signature, which require several, and what happens when a certificate is revoked.
Keys are stored in the protected perimeter of the device, and the application does not leave them in plaintext.
What if you need to change the vendor or build the application in-house?
Documentation handover is part of delivery: you receive the source code, integration schemas, signing policy descriptions, and build instructions. This is enough to maintain and develop the application without us.
What the client receives:
- integration configurations with the accounting system and a description of the exchange points;
- an access and role matrix with permission separation;
- signing policies for each document type;
- a rollback regulation and the procedure for returning to the previous version;
- instructions for building, releasing, and updating the application;
- a description of signing key storage and rotation;
- a change log and an acceptance checklist.
Describe your accounting system and signing scenarios — we will come back with an estimate and an integration plan.
Timeline of mobile signature implementation stages
The timeline depends not on the amount of code, but on how many external systems need to be brought together: the certification authority, document storage, corporate login, and approval of a legally significant signature format.
That is why the plan is built in waves — each ends with a working result that can be shown to the security service and lawyers.
The stages partially run in parallel: while the core is stabilizing, integrations can already begin on the test environment.
We separately set aside time for coordination with lawyers — requirements for the signature format and document retention period are often revised along the way.
What if we have our own certification authority? Then the integration stage is shortened, but compatibility testing of the issued certificates with mobile key stores is added.
What if offline mode is needed? The signature is generated on the device, while sending and status verification happen when a connection appears; this lengthens the core by 1-2 weeks.
Describe your signing scenarios — we will come back with an estimate and a stage-by-stage plan.