http://github.com/dylang/node-rssGatsbyJSTue, 31 Mar 2026 13:37:08 GMThttps://docs.idura.app/changelog/2026-03-13changelog/2026-03-13Tue, 17 Mar 2026 00:00:00 GMT This is a notice that, from 2026-04-17, we will always render the latest view version (currently 2025-01-01), for all customers **without** any custom CSS, or custom UI. You can check if this change affects you by going to [https://dashboard.idura.app/styling](https://dashboard.idura.app/styling). - If the `View version` field shows `2025-04-01`, you are already on the most recent version, and you will not be affected by this change. - If the `View version` field shows `Unified`: - If you **are not** using custom CSS, or custom styling, you will be switched to the new version. - If you **are** using custom CSS, or custom styling, nothing will happen. However, we still urge you to test the new version in your own time, and switch to it as soon as possible. ## What happens when the view version is changed? In July 2025, Swedish BankID introduced stronger accesibility requirements around QR codes ( [see the original changelog entry](/changelog/2025-04-02-sebankid-accessibility/)). This lead us to change the HTML and CSS we use to render the QR code, which again might break any custom styling of the QR code on your side. Upgrading to the `2025-04-01` view version also brings multiple new features (such as new eID logos) and bug fixes. https://docs.idura.app/changelog/2026-03-06changelog/2026-03-06Fri, 06 Mar 2026 00:00:00 GMT ## Support PDF signature seal scaling in Signatures Up until now the PDF signature seals were using default dimensions, however, to support cases where the seal might be too big, it is now possible to define a scale. The scale supports the range 0.2 to 1.0, both included, in increments of 0.1. In case of other values that fall in that range, the scale value will be rounded down, e.g., `0.2345 => 0.2`. See [PDF signature seal scaling example](/signatures/graphql/examples/#custom-seal-position-with-scaling). https://docs.idura.app/changelog/2026-01-28changelog/2026-01-28Wed, 28 Jan 2026 00:00:00 GMT ## Logo on eID selector page in Signatures Previously, the logo was only seen on the documents overview page that was only present when the signature order contained more than one document. However, now the logo is both shown on the documents overview page as well as the eID selector page. https://docs.idura.app/changelog/2026-01-19changelog/2026-01-19Mon, 19 Jan 2026 00:00:00 GMT ## Removal of PDF bookmarks When combining multiple PDF documents in Adobe, a default enabled option creates bookmarks for each of the combined PDFs. Attempting to sign such a combined document likely renders the signatures invalid as Adobe believes the document to have been altered. We have extended the `PadesDocumentInput`, when creating a signature order, with a property `removeBookmarks`. Bookmarks will be removed from the signed document(s) where the flag is set. To better support flexible flows, e.g., let the end user decide, the `validateDocument` mutation returns whether the provided document contains any bookmarks. Drawback is that users that previously relied on the bookmarks for navigation will no longer have the option, however, signatures are now correctly shown as valid. Please note: bookmarks generated from headings in Word or Google Docs don't suffer the same issue, it's only _after_ such PDFs have been combined the issue occurs. https://docs.idura.app/changelog/2025-12-18changelog/2025-12-18Thu, 18 Dec 2025 00:00:00 GMT ## EUTL for Signatures The Idura Signatures product will move from AATL to EUTL certificates and timestamping on January 8th, 2026. This has no negative effects\*, but has the positive effect that signed documents can now be validated in both Adobe and the EU DSS validator. _\* Users with very old versions of Adobe Reader will have to update their EUTL trust list in the Adobe Reader Trust Manager._ https://docs.idura.app/changelog/2025-12-09changelog/2025-12-09Tue, 09 Dec 2025 00:00:00 GMT ## Signatory Roles **Signatory roles** are used to designate what actions a given signatory is allowed to perform. A signatory's role can be set when adding a signatory to a signature order. Signatory roles aim to cover complex signing scenarios, such as, requiring specific people approve before a signature order can be closed/signed **or** allowing certain people access to the signature order thoughout its lifetime. Please read the more in-depth guide under [Signatures > Guides > Signatory Roles](/signatures/guides/signatory-roles/) https://docs.idura.app/changelog/2025-11-25changelog/2025-11-25Tue, 25 Nov 2025 00:00:00 GMT ## Norwegian BankID QES Stø, the company behind BankID requires that all merchants move to their new Signing API. This is beneficial, in that future signatures with BankID will be at the highest European level, QES. However, as signatures will then no longer be based on JWTs, it has a few breaking changes: - A new `Signature` GraphQL subtype has been added, `NorwegianBankIdSignature` of which you can request `claims`. - Evidence Validation must be done on either `ssn` or `uniqueuserid` to work. - `ssn` scope must specifically be added to evidence provider settings if `nnin` is required. Please note: Norwegian BankID QES with [CSC](https://developer.bankid.no/bankid-esign-provider/apis/csc/CSC/) carries an increased eID cost per document.https://docs.idura.app/changelog/2025-11-12changelog/2025-11-12Tue, 04 Nov 2025 00:00:00 GMT ## Viewer role You can now specify a `signatoryRole` when adding signatories. In addition to the default `SIGNER` role, a new `VIEWER` role lets you add participants who can view the documents without signing. Viewers do not block signing in parallel flows and can download the signed document once the signature order has been closed. https://docs.idura.app/changelog/2025-10-8changelog/2025-10-8Wed, 08 Oct 2025 00:00:00 GMT ## Signing sequence You can now control signing order in your signature workflows by setting a `signingSequence` on signatories. Signatories with lower numbers sign first, while those with the same number can sign in parallel. An example can be found in the [Signatures documentation](/signatures/graphql/examples/#signing-sequence). https://docs.idura.app/changelog/2025-08-15changelog/2025-08-15Fri, 15 Aug 2025 00:00:00 GMT ## Custom seals page template We added [custom seals page template](/signatures/graphql/examples/#custom-seals-page-template) to the Signatures API. The new add-on feature gives you full control over the signature seals page. Instead of the default blank page, you can now provide your own branded PDF template, making it easy to add your company's logo and colors to the signed document. Walk through an [interactive tour](/signatures/guides/custom-seals-page-template/#interactive-tour) to see it in action. https://docs.idura.app/changelog/2025-04-25changelog/2025-04-25Fri, 25 Apr 2025 00:00:00 GMT ## Swedish FrejaID Authentication via Idura Verify now supports [Swedish FrejaID](https://org.frejaeid.com/en/freja-eid-corporate/). With FrejaID, you can authenticate users in Sweden even if they do not have a Swedish personal identity number. This unlocks government-approved electronic ID for historically under-served segments of the population such as recent immigrants. If you are interested in testing it out for yourself, [read our documentation on FrejaID](/verify/e-ids/frejaid) to get started. https://docs.idura.app/changelog/2025-04-03changelog/2025-04-03Thu, 03 Apr 2025 00:00:00 GMT ## New `changeSignatureOrder` mutation We have introduced a new mutation that enables changing a signature order after creation. Initially it supports changing maxSignatories until the first signatory has signed. Please reach out if you have other needs for modifying signature orders post creation. [An example](/signatures/graphql/examples/#changing-signature-order) can be found in the Signatures documentation. The mutation is supported in [.NET](https://www.nuget.org/packages/Criipto.Signatures) and [Node.JS](https://www.npmjs.com/package/@criipto/signatures) SDK v1.21.0. https://docs.idura.app/changelog/2025-04-02-sebankid-accessibilitychangelog/2025-04-02-sebankid-accessibilityWed, 02 Apr 2025 00:00:00 GMT From July 2025, stronger requirements regarding accessibility must be fulfilled to meet legal demands. Amongst other things, these will affect the two-device flow for BankID where the animated QR code is used. [Learn more about the new requirements](https://developers.bankid.com/getting-started/qr-code#accessibility) In order to comply with the new QR code UI requirements, Idura must make adjustments to our UI (HTML & CSS), so that users may click the QR code to view it in fullscreen. This can cause breaking changes to customers who have custom CSS, so customers must explicitly enable the UI update. To comply with the new requirements, you must enable the UI update before July 2025. You can opt-in to the UI update for the test environment, and even per application, before doing so in production. To opt-in at a tenant environment level: 1. [Open dashboard](https://dashboard.idura.app) 2. [Navigate to Styling screen](https://dashboard.idura.app/styling) 3. Select 2025-04-01 in the "View version" dropdown 4. Click save To opt-in at an application level: 1. [Open dashboard](https://dashboard.idura.app) 2. [Navigate to Applications screen](https://dashboard.idura.app/applications) 3. Select the application you wish to upgrade 4. Click the "UI" tab 5. Disable "Use default" for the "View version" option 6. Select "2025-01-04" in the "View version" dropdown 7. Click save https://docs.idura.app/changelog/2025-02-20changelog/2025-02-20Thu, 20 Feb 2025 00:00:00 GMT ## German Personalausweis Authentication via Idura Verify now supports the German national identity card Personalausweis. This means that you can now electronically authenticate users in Germany quickly and easily. You can [read more about the Personalausweis](https://www.personalausweisportal.de/Webs/PA/EN/home/home-node.html) on the German government Personalausweis portal. If you are interested in testing it out for yourself, [read our documentation on Personalausweis](/verify/e-ids/german-personalausweis) to get started. ## Batch signatories for signatures As a step towards enabling interacting with large batches of signature orders, we have introduced a feature for batching signatories across one of more signature orders. A batch signatory can then be used to invoke a single action and have it performed automatically across every signatory. As batch signatories can be used to sign multiple, different signature orders at once, some requirements exist. A more detailed explanation, and interactive tour, can be found at the [batch signatory guide page](/signatures/guides/batch-signatory/). https://docs.idura.app/changelog/2025-01-15changelog/2025-01-15Sat, 25 Jan 2025 00:00:00 GMT ## Signatory UI settings Historically signature UI settings for users have been configured globally on the signature order. This had some drawbacks, as users might reside in different countries and prefer different languages. It is now possible to also define UI settings on a per signatory basis, [See example](/signatures/graphql/examples/#signatory-ui-settings) ## Webhook signing Until now, there was no way to validate the authenticity of a signature webhook at the time of the request. We relied on the fact that webhooks contained no actual data, but only identifiers, allowing clients to query our API based on the data in the webhook. This ensured that only authenticated clients could access signature data. However, it was brought to our attention that an attacker could use the webhook to increase the number of requests a well-behaving client would have to make to our API, potentially triggering rate limits. To address this, we introduced the option to configure a webhook secret, which adds an HMAC-SHA256 signature to each signature webhook invocation. You can read more about [configuring and validating webhook secrets](/signatures/webhooks/configuration/) and also try it out in our [webhook tester](/signatures/webhooks/tester/). https://docs.idura.app/changelog/2024-10-04-mitid-controlled-transferchangelog/2024-10-04-mitid-controlled-transferFri, 04 Oct 2024 00:00:00 GMT Authentication via Idura Verify now supports starting a session for MitID Controlled Transfer. MitID Controlled Transfer lets you perform cross-broker SSO, that is, transfering an authenticated MitID user from one service provider to another, without requiring the other service provider to reauthenticate the user. This is useful for cases where shared data services may require a valid MitID authentication to serve data for the user, but you do not wish to trigger authentication twice for the user. [Read the guide on how to implement Controlled Transfer](/verify/e-ids/danish-mitid/#controlled-transfer)