Guarded like the evidence it is.
Encrypted end to end, signed only after the signer has been checked, and sealed so that any later change shows. Including, further down, the things we deliberately do not claim.
What is protecting it right now
- In transitTLS 1.2+ · HTTPS enforced
- At restAES-256 · workspace scoped
- SignerOne-time passcode · single use
- RecordAppend-only · hash-chained
- ArchiveSealed · publicly verifiable
Every connection to eFirma is encrypted and redirected to HTTPS, including the links signers open on a phone.
Documents, evidence and the audit trail are encrypted on the disks they are stored on.
Every sealed document has one. Verification recomputes it from the file in front of you.
Each event is chained to the one before it, so a removed line is as visible as an altered one.
What actually happens to a document you send.
Four stages, each with something protecting it. A reviewer can follow this in the same order as the document itself.
- 01
Upload
The file arrives over an encrypted connection and is written to storage encrypted, inside the workspace that owns it.
- Encrypted in transit and at rest
- Scoped to one workspace
- Original kept unchanged
- 02
In flight
Each signer gets their own link. A link reaches one envelope, expires, and never carries an account or a password with it.
- One link per signer
- Expires after the envelope closes
- No account required to sign
- 03
Signing
Identity is confirmed with a one-time passcode before anything can be signed, and what happened is recorded as it happens.
- Passcode over SMS or email
- Time, address and device recorded
- Consent captured before signature
- 04
Sealed and archived
The finished document is fingerprinted and sealed, the trail is closed, and both can be checked by anyone holding the file.
- Fingerprint taken of the final file
- Tamper-evident seal applied
- Verifiable without an account
Who can do what, and how we know it was them.
Passcodes before signatures
A signer proves control of the phone number or mailbox the document was sent to before they can sign it. The passcode is short-lived and single use.
Roles that actually restrict
Administrators, senders and viewers see and do different things. Administrative operations are refused for anyone else, not merely hidden from them.
API keys with scopes
Integrations get a key limited to what they need — read, write, or administrative — and revocable on the spot without touching anyone's login.
Sign-in for your team
Password or Google and GitHub sign-in, with sessions bound to a workspace. Switching organisation re-issues the session rather than widening it.
Every action attributed
Sent, opened, signed, declined, downloaded, deleted — each entry names the person or key behind it, in the workspace's own record.
Retention you decide
How long completed documents and their evidence are kept is a setting in your workspace, not a default we chose for you.
Why a sealed document can be trusted by someone who does not trust us.
The point of the model is that it does not rest on our word. Everything below can be checked against the file in the reviewer’s own hands.
A fingerprint of the file
The signed document is reduced to a fingerprint at the moment it completes. Change one character afterwards and it no longer matches.
SHA-256A trail that cannot be edited quietly
Events are appended, never rewritten, and each carries the one before it. Deleting a line breaks the chain in a way verification reports.
Hash-chainedA seal applied by the platform
eFirma seals the completed record so that any later alteration is detectable. The seal attests to the record, and is ours rather than the signer's.
Tamper-evidentCheckable by someone outside
A registrar, a counterparty or a court can verify the document they hold without an account, without our help and without taking our word for it.
Public verificationThe unglamorous half: how the service is operated.
Most incidents are not clever. They are a change nobody read, a backup nobody tested, or an access nobody removed.
Kept in region
Documents, evidence and signer records are stored in region. Where a third party is involved in delivering the service, it is named in the sub-processor list rather than described as infrastructure.
Backups, and the ability to use them
Data is backed up daily and held to a schedule. A backup nobody has restored from is not a backup, so restores are exercised rather than assumed.
Least privilege for our own staff
Nobody here reads customer documents as a matter of course. Access for support is granted for a named reason, limited in time and recorded.
Changes are reviewed before release
Every change is read by a second engineer, released in small increments, and revertible. Small releases are how we keep them uneventful.
Watched while it runs
Availability, errors and the queues behind sending are monitored and alert a person. An incident that affects your documents is told to you, not discovered by you.
Written to the Proclamation
The controls above exist because Electronic Transactions Proclamation No. 1205/2020 expects a signature to be attributable, intact and evidenced — not because a checklist asked for them.
What eFirma does not claim.
A security page that lists only strengths is of no use to the person reviewing it. These are the limits of what we do, in our own words, before someone else phrases them less kindly.
- 01
We are not a licensed certificate provider
Ethiopian law reserves its strongest presumption for signatures backed by a certificate from a provider licensed to issue them. eFirma does not issue certificates and does not claim that tier. Our signatures are electronic, and their weight comes from evidence: a verified signer, a complete trail and a sealed document.
- 02
The seal is the platform's, not the signer's
It proves that the completed record came from eFirma and has not been altered since. It is not a key held by the signer under their sole control, and we will not describe it as one.
- 03
We publish assurance we have finished, not assurance we intend
You will not find an audit badge on this page in advance of the audit that earns it. If a procurement file needs our current position on independent assessment, ask and you will get a straight answer in writing.
- 04
Third parties are involved, and they are named
Message delivery, payments and hosting are not all done by us. Who does what, and what they can see, is listed in the sub-processors document rather than left to the phrase 'trusted partners'.
- 05
Security is not a plan tier
Encryption, identity checks, the seal, the audit trail and public verification are the same on the free plan as on the largest one. Paying more buys volume and control, never a stronger signature.
The detail behind the last two sits in the sub-processor list and the privacy notice. Both are dated, and both change before the practice does, not after.
Found something? We would rather hear it from you.
Write to [email protected] with what you did, what happened, and roughly when. A working case beats a scanner report, and one clear paragraph beats both.
A person — not an autoresponder — confirms we have your report within two working days.
We come back with whether we could reproduce it, how we rate it, and what we intend to do.
Critical issues are fixed within a week; high within thirty days; the rest in a scheduled release.
We will name you when the fix ships, or keep you anonymous. Your choice, asked before we publish.
Test within these lines
- Test against your own workspace and your own documents
- Stop at the first sign you can reach someone else's data, and tell us
- No denial of service, spam, or load testing against production
- No social engineering of our staff, customers or signers
- Give us reasonable time to fix before publishing
Research that stays inside them is research we welcome. We will not pursue a report made in good faith under these rules, and we will say so in writing if you need us to.
Usually out of scope
- Missing headers or configuration with no demonstrated impact
- Reports produced entirely by a scanner, without a working case
- Rate limits on endpoints that require no authentication
- Issues in third-party services — report those to them, and tell us
- Weaknesses already listed on this page as something we do not claim
Send it anyway if you think it matters and we have got this wrong. The list is a guide to what we can usually act on, not a door being shut.
Reporting on behalf of a customer’s review?
Penetration tests against a workspace you own are fine and do not need our permission. Tell us the window in advance and we will keep your traffic out of the abuse controls — and tell you what we saw afterwards.
Do not take our word for any of it.
Send one document, then check it yourself on the verification page — the fingerprint, the seal and the full trail, without an account.