Enterprise security — protection at every layer.
When you build legal signing on top of our platform, you are trusting us with sensitive documents and real identities. Wthaiq is a documentation and evidence authority for transactions and contracts, built on the principle of defense in depth. Encryption for every connection, least-privilege authentication, strict data minimization, documented Egyptian legal standing, and availability we target at 99.9%.
Defense in depth, not a single layer.
We do not rely on a single security control. Our layers intersect — encryption, authentication, data minimization and legal standing — so breaching one layer is not enough to expose your documents or your signers' data.
Confidentiality
All your data travels over a channel encrypted with TLS 1.2+. Only the holder of a valid key or an authorized role can access it.
integrity
Every document has a hash HMAC-SHA256 for platform contracts (and SHA-256 for uploaded PDFs), plus a tamper-proof chronological audit trail. Any modification, even a single bit, breaks the fingerprint match and is detected immediately on verification.
Availability
Regular off-server backups and an incident response plan, targeting 99.9% availability. And a public status page that shows the current state live.
Encrypted in transit, signed at completion.
We protect data as it crosses the network and as events are delivered to your servers. And we seal every completed document with a fingerprint and a digital signature that expose any later change.
Encryption in transit
Every connection to our APIs and signing pages goes over TLS 1.2 or later exclusively, so no sensitive data travels over an unencrypted channel.
A signed record for every contract
When signing completes we build a record and sign it with an asymmetric signature using Ed25519. Any party can verify it with our published public key, without coming back to us.
Document integrity hash
Every document has a cryptographic hash HMAC-SHA256 for platform contracts (and SHA-256 for uploaded PDFs), recorded in the audit trail and the certificate of completion, so it reveals any later modification, however slight.
Signed Webhooks
Every event we send to your servers is signed with the header Wthaiq-Signature via HMAC-SHA256 with your secret key, together with a timestamp to check freshness.
Key management
We keep signing keys and API keys separate from usage data. And we manage each of them through a clear lifecycle covering creation, rotation and revocation, without exposing them in the logs.
Accredited timestamp
A timestamping authority (TSA) issues a timestamp under RFC 3161 that fixes the time of signing; it is kept with every completed document's record, and embedded inside the digital signature in PAdES format when signing with a token.
HMAC-SHA256 over "the timestamp + the raw request body". Then compare the result with a constant-time comparison via hash_equals, and reject any request whose time difference exceeds 300 seconds.A strict identity, and least privilege.
No one reaches your data without a valid key and a defined role. Keys for systems, passwordless human sign-in, and fine-grained team roles.
API keys: secret and publishable
Two separate types: sk_… secret, with full permissions, used on the server only; its sends are actually billed unless it is a test key (sk_test_), which charges no balance and sends no messages. And pk_… publishable, safe to expose in the browser, locked to your domains (allowed_origins), and limited to a fixed set of paths. The type is determined by the key prefix alone.
Least privilege
Every key and role is granted the narrowest scope possible to do its job. No excess privileges, so the impact of any leaked key is confined to the narrowest limits. You can also restrict each secret key to specific IP addresses or address ranges, so any request from another address is rejected with 403 ip_not_allowed.
Key rotation
Rotate a key in the developer console and a new key is issued at once, while the previous key stays valid for 24 hours and then stops automatically, so you can move your server without downtime. If the key has leaked, stop it as soon as you rotate.
Track key usage
Every key carries a name, an identifying prefix and a last-used date last_used_at, so you can monitor active and idle keys and revoke any suspicious one immediately.
Passwordless human sign-in
Your team members sign in to the developer console with a one-time code OTP sent to their email, so there are no permanent passwords to leak or be reused.
Team roles
Distribute permissions across clear roles, so each member sees only what their role covers and nothing beyond it.
Account verification before sending live
An account cannot send live requests until its company verification is approved: an identity check of its representative, then a review of its documents, so every signer knows who is asking for their signature. A refused request returns 403 kyb_required.
Return URL on an accepted domain
After signing, the signer is redirected only to an https URL on a domain whose ownership you proved and the Wthaiq team accepted, and the URL is checked again each time the signing page is opened. The return is for display only: rely on the signed webhook for the result, not on the URL parameters.
One account per domain
A domain that one account has proven or had accepted cannot be added by another account, and other accounts' requests for the same domain are closed once ownership is proven. So no account can use someone else's domain in a return URL or in its publishable keys.
sk_… Server-side secrets only. For signing embedded in your interface, use a publishable key pk_… locked to your domain, or request a short-lived session token from your server via signing_session instead of exposing the key.We store the minimum required, and nothing more.
We adhere to data protection principles: we collect only what the service needs, set a retention period for each type of data, and sign a data processing agreement on request.
Per-account data isolation
Your documents are tied to your account alone, so no other account can browse or search them. And a signer reaches only the document they have been asked to sign.
Data minimization
In signer identity confirmation, we store The identity verification result and decision (approved/rejected), not the raw identity images. We keep the minimum that proves legal standing, and no more.
Retention policy
Each data type has a defined retention period appropriate to its legal purpose. Data is deleted or anonymized once that purpose ends, in line with a published policy.
Data processing agreement (DPA)
We provide a data processing agreement (DPA) to enterprise customers on request, setting out the controller and processor roles and the obligations of each.
Alignment with data protection principles
Built on the principles of personal data protection: a specified purpose, minimization, security and the rights of data subjects. We are committed to complying with the applicable requirements.
Sub-processors
We use a limited number of trusted sub-processors, and we disclose them transparently, together with the precise purpose of each.
Identity verification with an official document and a live face match. We receive the verification decision, not the raw identity images.
Processes subscription payments securely, without card data passing through our servers.
A trusted RFC 3161 timestamp that proves the moment of signing and is kept with the evidence record, and is embedded inside the digital signature when signing with a token.
Legal standing built on Egyptian law.
Signing technically is not enough; the signature has to hold up before the courts and the regulators. Wthaiq is a documentation and evidence authority for transactions and contracts, and its legal framework is explicitly Egyptian.
The Electronic Signature Law
The work is based on Egyptian Electronic Signature Law No. 15 of 2004 and its executive regulations, under the supervision of the Information Technology Industry Development Agency (ITIDA).
Signing with the customer's token
We are not a certification authority and we do not issue certificates. Where someone signs with their own token, we embed their signature inside the file and preserve it with its chain and its timestamp. The certificate is issued by their licensed authority, not by us.
PAdES signing up to LTA
We apply the full PAdES ladder to the embedded copy. It starts at B, moves to T with the timestamp, then LT with the validation material, all the way to LTA with an archival timestamp that keeps the legal standing intact for many years.
A tamper-proof audit trail
Every event is recorded chronologically — opening, viewing, verification and signing — together with the IP address and the user agent, in a log that cannot be altered retroactively.
A cryptographic hash that reveals tampering
Hash HMAC-SHA256 for platform contracts (and SHA-256 for uploaded PDFs) is recorded for every signed document, so any later modification breaks the fingerprint match and immediately shows the status modified during public verification.
Public verification by reference
Every completed document has a public verification reference WTQ-XXXXXXXXXXXX It lets any party confirm its integrity and its parties through The verification page with no account required.
Built to stay available.
We target 99.9% availability through off-server backups and an incident response plan. And graceful degradation keeps signing running when any supporting service goes down.
We take a full copy of the database and upload it to cloud storage separate from the server, so a server failure does not take the copy down with it.
We check the integrity of every file as soon as it is created and reject an incomplete one before uploading it. And an on-demand verification tool imports the copy into a separate database and compares its tables and rows against the original.
A documented response plan with clear roles and escalation, including notification of the affected customers and a post-incident analysis for every material incident.
If the timestamping or LTV service is temporarily unavailable, signing continues at the lowest valid level, and the level actually reached is recorded.
Security controls at a glance.
A summary of the core controls and their status. "Enabled" = in place today, "Committed" = a principle we apply and are working to document, "Target" = a percentage we strive for and do not guarantee, and "On request" = available to enterprise customers.
| Category | Control | Status |
|---|---|---|
| Encryption | TLS 1.2+ in transit for all connections | Enabled |
| Encryption | An Ed25519-signed record for every completed contract | Enabled |
| Encryption | Webhooks signed with HMAC-SHA256 | Enabled |
| Integrity | A digital fingerprint for every document (HMAC-SHA256 for platform contracts, SHA-256 for uploaded PDFs) with an audit trail | Enabled |
| Access | Separate API keys (secret/publishable) + rotation | Enabled |
| Access | Secret keys can be restricted to specific IP addresses | Enabled |
| Access | Passwordless human sign-in via OTP | Enabled |
| Access | Least-privilege team roles | Enabled |
| Privacy | Each account's data isolated from the rest | Enabled |
| Privacy | Data minimization (the signer identity confirmation decision, not the raw identity images) | Enabled |
| Privacy | Alignment with personal data protection principles | we adhere to |
| Privacy | Data Processing Agreement | On request |
| The law | Electronic Signature Law No. 15 of 2004 (ITIDA) | Enabled |
| The law | Embedding the customer's token signature inside the file and preserving it | Enabled |
| The law | PAdES signature up to LTA level | Enabled |
| Reliability | 99.9% availability | Target |
| Reliability | Off-server backup with an integrity check for every copy | Enabled |
| Reliability | A public status page with an automated self-check | Enabled |
| Governance | Responsible disclosure via security@wthaiq.com | Enabled |
Found a vulnerability? Tell us first.
We welcome security researchers and value their work. If you discover a vulnerability, contact us directly before publishing any details, and we commit to handling it seriously and within a published response window.
Write to our dedicated address with the steps to reproduce the vulnerability and the expected impact.
Do not publish details of the vulnerability before it is fixed, and do not use real user data during your research.
We acknowledge receipt within a response window, work on the fix and then inform you, and we appreciate responsible disclosure.
Security questions before you rely on us.
Who can access our data?
Only someone holding a valid key or an authorized role reaches your data. All data travels over a channel encrypted with TLS 1.2+, and we govern access to it by least privilege through API keys and passwordless human login. And your documents are tied to your account alone, so no other account can browse them.
Do you keep signers' identity images?
No. We apply data minimization: we store the identity verification result and its decision (approved or rejected, and the level) from the a specialized identity-verification provider, not the raw identity images. What legal standing requires is proof that the verification took place and what its outcome was, and reducing what we keep reduces what can be lost or misused.
How do I verify that a Webhook event really comes from you?
Every event carries a Wthaiq-Signature header in the form t=<timestamp>,v1=<signature>. Compute HMAC-SHA256 over the text "the timestamp + a dot + the raw request body" using the endpoint secret whsec_. Then compare the result with a constant-time comparison, and reject any request whose time difference exceeds 300 seconds. See the implementation details on The Webhooks page.
What availability level do you commit to, and how do I track it?
We target 99.9% availability — a figure we strive for, not one we guarantee. We back it with off-server backups and an incident response plan. If the timestamping service is temporarily unavailable, signing continues at a lower level, and the level actually reached is recorded. Follow the automated check result and the fault log on The public status page.
Are your signatures legally accepted in Egypt?
Yes. The work is based on Egyptian Electronic Signature Law No. 15 of 2004 and its executive regulations, under ITIDA supervision. We are a documentation and evidence authority, not a certification authority. The strongest thing we offer on our own is signing with identity verification, with an audit trail and a fingerprint that reveals any change. And where someone signs with their token, we embed their signature inside the file up to PAdES-LTA level. For a breakdown of the legal standing levels, see The trust page.
Build on infrastructure you can trust.
Monitor our availability in real time on the status page, or contact our team for a data processing agreement or an enterprise security inquiry.