Skip to main content

Express Signature

On this page, you can find information about changes that you need to make if you are a customer using Norwegian BankID with Express Signature.

What customers are affected by this?

This applies only when using Norwegian BankID with the mechanism set to pkisignature. If you are using authentication only (with the mechanism set to identification), you are not affected and no changes are required.

Required changes for affected customers​

Deadline: 01.03.2026​

  • You will no longer be able to do XML signing using Norwegian BankID.

  • The new method for Norwegian BankID Signature Consortium API, which you should set as no_bankid_csc in the request, will be available for you in January. Once available, you need to switch to this method as soon as possible, by 1 March 2026 at the latest.

    Important

    If you do not migrate before the deadline, we will automatically switch your integration to the new method. This automatic switch comes with the following limitations:

    • You will no longer receive a combined native signer file.
    • There is a higher risk that your integration may break due to the changes described in this document.

    If you do not do this, then you risk losing the ability to sign documents once the old signing method is decommissioned.

  • If you use signers.documentSignature.attributes in the Get document or Get signer endpoints, then the following BankID-specific attributes will no longer be returned:

    • UserCertOriginator
    • UserCertIssuerBank

  • If you are using the signature solution inside a sandboxed iframe, the iframe must allow opening new tabs. Make sure the sandbox attribute includes allow-popups, for example: <iframe sandbox="allow-popups …">

  • If you are downloading the native signer file from either of the following endpoints, then this will change from a SEID_SDO to a DSS PAdES file with the new signature method:

    • /documents/{documentId}/files/signers/{signerId}
    • /documents/{documentId}/files/attachments/{attachmentId}/signers/{signerId}

  • If you are downloading the packaged file from either of the following endpoints, then this will change from containing a SEID_SDO to a PAdES file with the new signature method:

    • /documents/{documentId}/files/signers/{signerId}
    • /documents/{documentId}/files/attachments/{attachmentId}/signers/{signerId}

Required changes for customers downloading the native combined file​

Deadline: 14.02.2026​

Note

This deadline is dependent on the document time to live and is applicable to customers who download and require the native file from one of the following endpoints:

  • /documents/{documentId}/files
  • /documents/{documentId}/files/attachments/{attachmentId}.

If you need a native signature containing all signatures, similar to the BankID SDO, then you must explicitly include native in dataToSign.packaging.signaturePackageFormats.

When "native" is included, then ordered signatures are required. If the order is not specified, then the API returns a 422 error. This is because signatures must be applied serially to ensure that they all appear in the same PAdES file as individual person signatures.

Want to learn more?

To learn more about setting up ordered signatures, see the Set up signer queue section on the How to create document page in our Enterprise platform documentation.

If you do not include the native package format, then the new native BankID PAdES is still generated, but it will only contain one end-user signature per signer. This means that a combined native package as previously available will not be created.

The Signicat PAdES will continue to be included as before, containing the individual signatures as evidence in the attached XML package.

On this page