Signatur produces Simple Electronic Signatures (SES) as defined in eIDAS Regulation (EU) 910/2014, Article 3(10). We are not a Qualified Trust Service Provider. We do not issue Qualified Electronic Signatures (QES) or Advanced Electronic Signatures (AES) on our own. We are not a BankID provider.
1. The eIDAS ladder
| Class | Identity assurance | Cryptographic assurance | Legal effect |
|---|---|---|---|
| SES (Art. 3.10) | None required | None required | Admissible (Art. 25.1) |
| AES (Art. 26) | Linked to signatory; capable of identifying | Sole-control creation data; tamper-evident | Stronger evidentiary weight |
| QES (Art. 3.12) | AES + qualified certificate | Qualified Signature Creation Device (QSCD) | Equivalent to handwritten (Art. 25.2); mutual EU recognition |
2. What Article 25 says
Art. 25(1): "An electronic signature shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements for qualified electronic signatures."
This is the foundation: an SES is admissible. The evidentiary weight depends on the surrounding evidence — identity verification, audit trail, document integrity. Signatur is built to maximise all three.
3. What we do — and don't — guarantee
We do
- Capture identity via email OTP (and, optionally, phone OTP, knowledge factor, or ID document upload — sender's choice per envelope)
- Hash-chain every event in an append-only audit trail (SHA-256)
- Lock the signed document with a sealed PDF hash on completion
- Maintain server clock via NTP for trustworthy timestamps
- Provide an evidence package (signed PDF + JSON audit + verification instructions) on completion
- Allow anyone to verify the document at /verify
- Retain audit chain for 10 years (configurable)
We don't
- Issue qualified certificates (not a QTSP)
- Apply qualified timestamps from a QTSP by default (available as add-on)
- Integrate BankID, Buypass, or other Norwegian eID schemes for identity (not in this MVP)
- Provide notarisation, apostille, or legalisation services
- Guarantee acceptance in every jurisdiction or for every document type
4. Document types — guidance
Signatur classifies documents into four risk levels at send time:
| Class | Examples | What we do |
|---|---|---|
| Standard | NDA, sales proposal, SOW, vendor onboarding, consulting engagement | Send normally |
| Elevated | Large MSA, IP assignment, SAFE, settlement agreement, license agreement, special-category personal data | Recommend stronger identity verification |
| High | Employment contract (remote/first-hire), termination, share purchase, long-term commercial lease, personal guarantee, consumer loan | Warn the sender; require an acknowledgment that SES is sufficient for their specific case |
| Not suitable for SES | Norwegian property transfers (Tinglysing), wills, marriage/divorce records, notarisation, tax filings, public-sector procurement requiring BankID | Block the standard send flow; offer alternative guidance |
This classifier is guidance, not legal advice. Sender remains responsible for choosing the appropriate signature class for the document at hand. When in doubt, consult counsel.
5. Why not BankID / QES today?
BankID and QES require integration with a Qualified Trust Service Provider and substantial assurance investment. Most SMB document types our customers send (NDAs, proposals, SOWs, vendor agreements) are well-served by SES with strong evidence — and SES dramatically reduces friction for recipients. We will integrate AES/QES via QTSP partnership when our customers' needs warrant it; see the roadmap.
6. Cross-border recognition
QES enjoys mutual recognition across all EU/EEA Member States (Art. 25.3). SES does not have automatic mutual recognition, but Art. 25.1 still applies — admissibility cannot be denied solely for being electronic. The evidentiary weight is governed by the law of the forum.
7. Norwegian specifics
The EEA-incorporated eIDAS regulation is implemented in Norway via Lov om elektroniske tillitstjenester. Nkom is the supervisory body for trust services. BankID operates as a federated scheme under Norwegian banks; some configurations produce qualified signatures. Signatur is not a BankID provider; the BankID brand and the QTSP status it confers are not implied by use of Signatur.
8. How to challenge or rely on a Signatur signature in court
The relying party should be able to demonstrate:
- The exact document that was signed (use the sealed PDF hash; re-verify at /verify)
- Identity of the signatory (audit trail's identity verification record)
- Intent to sign (the consent acknowledgment captured)
- Time of signing (audit timestamp; optional qualified timestamp)
- That nothing changed after signing (sealed hash; immutable storage)
The downloadable evidence package contains all of the above in court-ready format. When introduced as evidence, the relying party should provide a copy and direct the court to /verify for independent verification.
9. Roadmap
Items under consideration (timing not committed):
- Qualified timestamps via QTSP (RFC-3161)
- BankID / EUDI Wallet identity integration via gateway partner
- AES support via PAdES + cloud HSM
- QES support via partnership with one or more Norwegian/EU QTSPs
10. Contact
Questions about signature class or admissibility: legal@signatur.app.