Security and compliance

Our premise is simple and non-negotiable: nobody accesses a document without entitlement, and no record can be altered without it becoming evident. Below is how that is implemented — not in promises, but in mechanisms.

01

Cryptographic document sealing (PAdES)

When the last signer completes, the platform assembles the final document — original files, manifest page and negotiation transcript — and digitally signs it with the operator's company certificate, in the PAdES standard. From then on, changing a single byte invalidates the signature, detectable in any compliant PDF reader.

  • PAdES-standard signature, recognized by national and international validators
  • Timestamp from an accredited authority when contracted, independently proving the date
  • Integrity check of original files against the hash recorded at upload, before sealing
02

Chained audit trail

Each relevant event is recorded in a chain where the next record carries the hash of the previous one. Altering an old event would require recomputing every later one — and the chain is verifiable at any time, including by external audit. The database refuses any attempt to edit or delete those tables.

  • Three independent chains: document journey, account actions and negotiation messages
  • Append-only enforced by the database itself
  • On-demand integrity verification plus a weekly automated routine
  • The chain is printed into the sealed document, enabling offline verification
03

Document access: the URL is never the key

Knowing or guessing an address grants nothing. Every download re-validates who is asking, at the moment of asking, and only then issues a temporary link to the file — expiring in 60 seconds. No permanent storage address is exposed to the browser, and invalid attempts are recorded.

  • Authorization re-validated on every access, never assumed from link possession
  • Signing links with 256 bits of entropy, expiry and revocation
  • Single-use mobile signing links, valid for 5 minutes
  • Attempt limits to prevent scanning and brute force
04

Isolation between organizations

Each company sees only its own data, and that boundary is enforced by the database through Row-Level Security — not just by application code. It is an extra layer: even a programming flaw is not enough to cross the separation between clients.

05

Identity and access

Accounts are global and roles are per organization, allowing participation in several workspaces with a single login and no duplicate registrations. Platform administrative access requires a second factor, and any support session that assumes a user's identity is recorded with the responsible/target pair.

  • Passwords protected with a modern derivation algorithm (Argon2id)
  • Second factor (TOTP) available to everyone and mandatory for platform administrators
  • Login with ICP-Brasil digital certificates, including revocation checking
  • Association invitations instead of recreating existing users
06

Data, infrastructure and continuity

Documents are stored encrypted at rest, with versioning and deletion protection. Traffic is always encrypted in transit. Database backups are generated periodically and shipped encrypted to external storage, with defined retention and a tested restore procedure.

07

Privacy and LGPD

We collect the minimum needed to sustain the legal proof of the signature. Signer data is processed as an operator, following the contracting company's instructions. Our infrastructure can be kept within Brazilian territory, and subprocessors are listed in the Privacy Policy.

What we do not do

  • We do not read, index or analyze the content of your documents
  • We do not record document content in system logs — only identifiers and hashes
  • We do not sell, share or use your data to train models
  • We do not allow signing pages to be indexed by search engines
  • We give no internal team silent access: support that assumes an identity is recorded
Security and compliance · JustSign