2 posts tagged with "security"

For a long time, advanced deletion of agreements has been reserved for larger contract customers with strict retention requirements.

Today, we’re happy to share that advanced deletion is now rolling out for all customers. This gives you more control over your data lifecycle — whether you want to reduce long-term storage, meet internal compliance policies, or simply keep your account clean.

Why deleting agreements can be complicated​

Deletion sounds simple on paper.

In practice, agreements are not just “files in storage” – especially once they’ve been signed. Signed agreements often involve multiple parties, and each signatory has a right to retain their own copy. At the same time, we have a responsibility to ensure a transparent and fair signing process for everyone involved. That’s why we’ve historically been careful about offering deletion too liberally, particularly for fulfilled agreements.

How advanced deletion works​

With this rollout, deletion is now available across all accounts – with safeguards built in.

Fulfilled (signed) agreements​

For agreements that have been completed, deletion is scheduled 30 days in advance. This ensures that every party has enough time to safely download their documents before anything is permanently removed.

Other agreement statuses​

For agreements that are not fulfilled, deletion is scheduled immediately (although it can take up to 30 minutes before the deletion process has been completed).

What happens after an agreement is deleted?​

Once deletion has been completed:

• All files are permanently removed
• All personal and document data is anonymized
• Nothing can be restored

However, we retain a minimal reference entry for your own records. You’ll still be able to see that an agreement existed, either:

• in your account history
• or via GET /agreements

Deleted agreements are omitted by default, but can be included when needed for audit and tracking purposes.

Can I still verify deleted agreements?​

Yes – absolutely.

One of our core principles is: Once signing is completed, our duty is done.

The documents produced through Zigned are fully self-contained. You should not need Zigned, or any additional system data, to verify or validate a signed agreement. It is your document and your data, we simply orchestrate the signing process.

Are agreements automatically deleted?​

No.

By default, agreements remain available in encrypted storage, as most customers prefer having long-term access to download copies when needed. Advanced deletion is completely opt-in so if you like things as they are today, nothing changes.

More control, same trust​

Advanced deletion is about giving you flexibility without compromising the integrity of the signing process. We’re excited to finally make this available to everyone — and we’ll continue building tools that help you stay compliant, secure, and in control.

Get started​

In order to get started, you need to upgrade your API client to version 3.4.0. You can do this by navigating to your API client settings on zigned.se and clicking "Upgrade".

When you need more than “a signature,” identity enforcement links a Swedish personal identity number (personnummer) to a signer and forces strong authentication (Mobile BankID/ZealID) before the signature can complete. If the authenticated identity doesn’t match, the signing is blocked.

What is the benefit of identity enforcement?​

Sometimes it is critical that a specific person is the one signing an agreement. For example, only a certain individual may be authorized to sign a purchase order. In the past, some providers such as BankID allowed you to initiate authentication for a specific personal number. However, this approach is becoming increasingly rare, since it creates security and impersonation risks. If a signing session can be triggered remotely for a given identity, there is no guarantee that the actual signer is the one present in the signing room. By requiring the scanning of a QR code or starting the authentication session directly from the signing room, these risks are significantly reduced.

The drawback is that anyone with access to the signing room link could still complete the signing. Because recipients sometimes share links carelessly, this can be a serious problem in compliance-heavy environments.

Our solution combines the best of both worlds. Instead of starting a signing session for a fixed personal number, identity enforcement cross-checks the signer’s identity after authentication. This ensures that impersonation and remote signing risks are mitigated while also discarding any invalid signatures.

How it works​

Identity enforcement must be configured while the agreement is still in draft. You attach the participant’s personal number under the identity_enforcement object. At signing time, the participant is required to authenticate using Swedish Mobile BankID. Zigned automatically cross-checks the authenticated identity against the stored personal number, and the participant’s status moves from pending to either passed or failed.

You can combine identity enforcement with a lower trust level to enforce stricter signing methods for a specific participant. For example, if you set trust_level: SES along with identity enforcement, the participant is only allowed to sign using advanced methods. Identity enforcement also works with qualified signatures (QES), ensuring the strongest level of eIDAS-compliant signing.

Privacy and compliance​

Personal numbers are handled with the same care as sensitive credentials. They are normalized and stored using hash-based encryption, meaning the original value is never persisted in plain form. All verification is done against these hashes, ensuring that identity enforcement is fully GDPR compliant while maintaining strong privacy guarantees.

Example: Creating a signer with identity enforcement​

// POST /agreements/:agreement_id/participants
import fetch from 'node-fetch'

async function addSignerWithIdentity(agreement_id: string, token: string) {
    const body = {
        role: 'signer',
        email: 'anna@example.com',
        name: 'Anna Andersson',
        personal_number: '198512149999',
    }

    const res = await fetch(`https://api.zigned.se/agreements/${agreement_id}/participants`, {
        method: 'POST',
        headers: {
            Authorization: `Bearer ${token}`,
            'Content-Type': 'application/json',
        },
        body: JSON.stringify(body),
    })

    if (!res.ok) throw new Error(`Create participant failed: ${res.status}`)
    return res.json()
}

Tracking outcomes​

When retrieving a participant, you’ll see an identity_enforcement object describing the state:

{
  ...participant,
  "identity_enforcement": {
      "enabled": true,
      "status": "passed",
      "enforcement_method": "swe_pno_crosscheck"
  },
}

A status of "passed" confirms that the participant authenticated correctly with the provided personal number. "failed" indicates that the identity check did not match, and the signing attempt is blocked.

In conclusion​

Identity enforcement is a powerful tool for ensuring that only the intended signer completes a signing process. Our approach not only enhances security but also ensures compliance with privacy regulations. To get started, you only need to pass in a personal_number when creating a participant. Easy-peasy!