Provenance & Verification

Don’t trust appearances. Verify the evidence.

Every message and file sent through We Secure Data comes with cryptographic evidence. Signed content fingerprints bind the exact content to the recorded sender identity and UTC time. Verification checks the signature and whether the content still matches.

A checkable record of the content you shared.

COMPANY-SPECIFIC CRYPTOGRAPHIC PROVENANCE

How We Secure Data’s company signing keys work

Each company has its own provenance signing identity. The platform selects the owning company’s active key for supported message and file evidence; another tenant’s key is rejected, and signing stops if the required company key is unavailable.

Separate companies. Separate signing keys.

Company A

Company A private signing keyManaged signing operation

Company A signed evidenceMessage or file provenance

Company A public keyRecipient verifies the signature

Company B

Company B private signing keyA separate company key

Company B signed evidenceIts own message or file provenance

Company B public keyRecipient verifies this signature

Company A’s signature does not verify with Company B’s public key. First establish that the public key belongs to the organisation you expect.

Private signing keys: managed protection

In hosted SaaS, company provenance keys are generated in Google Cloud KMS using ECDSA P-256 with SHA-256. The private component stays in the managed key service. We Secure Data’s authorised services request signatures through controlled service identities; cloud access controls govern signing access and the application checks company ownership.

This is a We Secure Data-operated signing service, not an exclusively customer-held private signing key. Customers do not download or export this private key through the app. Dedicated deployment key ownership and operational access follow that deployment’s agreed configuration.

Public keys: verify the right company

Evidence identifies its signing key and version and includes public-key material or references. The existing HTTPS issuer key registry publishes relevant public keys and fingerprints. Use a trusted organisation or issuer source, or independently confirm the expected fingerprint.

Where configured, domain verification uses a DNS or website challenge, or an administrator-managed verification process. Workspace membership and verified domain control are useful context; a valid signature alone is not independent certification of a company’s legal identity.

What the signature covers

Verification checks canonical signed provenance: the included message or document subject, actor and version fields, and file hashes. The verifier checks the corresponding files against the covered fingerprints. Changing covered content causes the relevant verification to fail.

Only fields in the signed payload receive that signature’s protection. The signature envelope, export packaging and bundle artifacts, and separately attached public-anchor material are outside this provenance payload and have their own verification rules. A label shown elsewhere in the interface is not automatically signed.

Independent and offline checks

Keep the complete exported evidence, required original files, supported verifier and trusted public-key material. Supported offline checks need no We Secure Data login or connection, and never need the private signing key.

An included public key can make the mathematics checkable; it cannot authenticate its own owner. Confirm the expected key separately. Optional live issuer-registry checks need a connection and are distinct from offline content verification.

Two checks. One stronger basis for trust.

Do we trust this public key’s company association? Establish that it is the expected organisation’s key using a trustworthy source.
Does the evidence verify under that key? Check the signature and the hashes of the content it covers.

Keys over time: rotation, historical evidence and revocation

Evidence records signing-key identifiers and versions. Retain the appropriate trusted public-key material for historical evidence: changing a current key does not change an old signature’s mathematics. Historical acceptance also depends on the relevant key status and policy.

The current company-key workflow does not offer customer self-service signing-key rotation or export. Key changes require operator-managed review of current and historical public-key availability. Offline verification cannot discover a later revocation without refreshed trusted information.

What a verified signature establishes

A successful check establishes that the covered data matches a signature made using the corresponding private signing key. It supports attribution to the stated company when that public key’s company association is reliably established.

It does not by itself identify the individual human author, prove every statement true, confer commercial authority, or establish an independently trusted time. Normal signing times are platform-recorded. Public audit-anchor evidence is a separate check.

Certified Forward: check the original company’s evidence

Supported Certified Forward gives the recipient access to provenance for the original message and files. The evidence is checked under the original owning company’s key, not merely the forwarding company’s branding. A fresh evidence export may be newly sealed using the original company’s current key; forwarding context is separate from that original-content provenance.

Explore key protection and security architecture → · Explore Independent Recovery →

CONFIDENCE BUILT ON VERIFICATION

Know the origin. Check the exact content.

A cryptographic signature connects the evidence to its signing key. Verify it against the intended organisation’s trusted public key, then check that the content matches. You get an independently checkable record of the exchange.

Read the guide to AI business impersonation →

Try the genuine-versus-altered quotation →

For the senderProve exactly what you sent.

Evidence is created from the protected content at the time of communication.

For the recipientVerify the recorded sender identity.

Check the recorded sender identity bound to the evidence rather than trusting appearance alone.

For bothVerify it hasn’t changed.

Compare the content with the signed fingerprint to detect a mismatch.

Under the proof

How provenance verification works.

Content prepared

An important message or document enters the protected exchange workflow.

Fingerprint created

A cryptographic hash is generated from the content.

Evidence signed

The digest is signed to bind supported origin and integrity properties to the content.

Recipient verifies

The recipient checks the recorded sender identity in the evidence and whether the content matches.

Independent checks

Supported documents can be checked offline when the original application is unavailable.

Reproduce the checks

Public protocol. Standard cryptography.

We Secure Data signs deterministic JSON evidence using ECDSA P-256 and SHA-256. Once the organisation public key has been obtained from a trusted source, a third party can verify the evidence without the We Secure Data application or original account.

Read the Cryptographic Protocol

What the evidence establishes

Know the origin. Verify the exact content.

We Secure Data verification checks the recorded identity and content properties bound to the evidence. Use that signed record to establish which content was shared, then apply your business approval process to the instructions it contains.

WHO

Sender evidence

Verify the recorded sender identity bound to the evidence.

WHAT

Exact content

Verify the content against its signed fingerprint.

UNCHANGED

Integrity status

Detect when protected content no longer matches.

Reading the result

What does a successful check mean?

The file matches the signed evidence and the signature verifies against the trusted public key. The identity and time are the values recorded by We Secure Data; the check does not independently establish a person’s real-world identity or provide a third-party timestamp.

Read the verification protocol →

Make your next important exchange verifiable.

Secure messages, protected files and evidence you can retain.

What the signature can establish.

A valid signature links the signed content to its signing key. The recorded sender’s account or organisation is part of that evidence, with domain membership verification where recorded. Independently establish that the key belongs to the intended organisation. The result does not prove human authorship, that a statement is true or that a payment instruction is safe.

Keep verification independent.

The supported downloaded verifier checks bundle content and signatures using included verification materials. A changed file should fail the applicable integrity check. Offline verification does not retrieve newly published keys or audit anchors; a bundled key is not, by itself, an independent guarantee of business identity. A pending public anchor is distinct from a failed file-integrity check.

Have your AI independently verify the bundle →Follow a recipient verification →See original evidence survive Certified Forward →Understand activity records versus provenance →