Security & Trust

All traffic between your browser or mobile app and AKMSign is served over HTTPS with TLS. Plain HTTP access is not offered.

Documents and database records are stored encrypted at rest by the managed cloud infrastructure AKMSign runs on. Signed archive copies are additionally encrypted with AES-256 before being written to long-term object storage.

Accounts sign in with an email address and password, or with Google sign-in. Passwords are stored only as salted hashes by the managed authentication service; AKMSign staff cannot read them.

Time-based one-time password (TOTP) multi-factor authentication is supported, and a workspace can require MFA for its members. Single-use recovery codes are issued so a lost authenticator does not lock an account out permanently.

Sign-up uses an emailed one-time code to verify the address before an account is created. Password resets are rate-limited.

On supported mobile devices the app can be locked behind the device biometric (Face ID / fingerprint).

Every member of a workspace holds an explicit role — administrator, sender, signer or viewer — and roles are stored separately from user profiles so they cannot be self-assigned from the client.

Permission checks are enforced on the server and in the database, not only by hiding buttons in the interface. A request that the caller's role does not permit is rejected regardless of how it was issued.

A workspace can never be left without an administrator; the last remaining administrator cannot be removed or demoted.

AKMSign is multi-tenant. Every document, recipient, template, invitation and audit record is bound to exactly one workspace.

Isolation is enforced by row-level security policies in the database, evaluated against the identity of the signed-in user on every single query. There is no query path that returns another workspace's rows.

Uploaded and completed documents are held in a private object-storage bucket. There is no public URL for a stored document and directory listing is not possible.

Access to a stored file is granted per request, for the specific user or verified recipient, and only after the same workspace and role checks that apply to the rest of the platform.

Original uploaded files are never modified. Signed output is written as a separate finalized object.

External recipients receive a signing link that carries a random, single-purpose token. Only a hash of the token is stored, so the link cannot be reconstructed from the database.

Each token is bound to one envelope and one recipient, expires after a workspace-configured period, and can be revoked at any time by the sender. Opens are counted and timestamped.

Internal recipients must be signed in to their AKMSign account before they can sign, in addition to holding a valid link.

Every meaningful event on an envelope — created, sent, opened, viewed, signed, declined, corrected, revoked, completed — is appended to an immutable audit trail with an actor, a timestamp and the relevant context.

On completion AKMSign issues a Certificate of Completion listing the envelope identifier, the participants, their verification steps and the full event history.

A SHA-256 hash is computed for each finalized document and recorded on the certificate, so any later alteration of a downloaded file can be detected by re-hashing it.

The application is served from a globally distributed edge network. Application data — the database, authentication records and the private document bucket — is held in a managed cloud region in the United Kingdom (London). The United Kingdom holds a UK/EU adequacy decision, so transfers between the UK and the EEA do not require additional safeguards.

Long-term encrypted archive and backup copies are held with a separate object-storage provider in a region selected for that purpose.

Email delivery, payment processing and push notification delivery necessarily involve transmitting the minimum required data to the subprocessors listed below, which may process it outside the European Union.

Database metadata is backed up on an hourly schedule and document objects are backed up to write-protected object storage, so a backup copy cannot be silently altered or deleted within its retention window.

When a subscription ends or a trial expires, the workspace becomes read-only for a defined retention period during which documents, certificates, audit trails and exports remain available for download.

Deleting an account or a workspace permanently removes its documents, stored files, members, invitations, signing tokens and audit records from production. Backup copies age out at the end of their retention window.

A workspace administrator can request a full export of the workspace at any time while the workspace is readable.

A legal hold can be placed on a whole workspace or on an individual envelope. While a hold is in force, deletion, purge and retention-driven removal are blocked for the held data, including by administrators.

Placing and releasing a hold is itself recorded with the actor, the reason and the timestamp.

AKMSign uses a managed cloud platform for application hosting, database, authentication and private document storage; a separate object-storage provider for encrypted archives and backups; a managed transactional email service for signing invitations, completion notices and account email; Paddle for payment processing and, where applicable, as merchant of record; and the Apple and Google push services for mobile notifications.

Subprocessors receive only the data required to perform their function. A current list with entity details is available on request to business customers.

Suspected vulnerabilities, exposed signing links and suspected account compromise should be reported to security@akmsign.com, or through the contact form, with enough detail to reproduce the issue.

Reports are acknowledged and triaged. Please do not publicly disclose an unresolved issue, and do not test against workspaces or documents that are not yours.

If a security incident affects your data, AKMSign will notify affected workspace administrators with what is known, what is affected and what action is required.

AKMSign runs continuous internal health monitoring across the application, the database, scheduled jobs, backups and email delivery, and raises alerts on failure.

AKMSign does not currently publish a public status page. Incidents affecting availability are communicated to affected workspace administrators by email.

Business customers who need a Data Processing Agreement, a subprocessor list, or answers to a security questionnaire can request one from the contact page or by writing to security@akmsign.com. Please include the legal entity name and the intended use.