Time now for WAYF members to configure new crypto keys

By Mikkel Hald, 16/12/25

This article contains important information for organisations participating in WAYF, and should be read carefully by their WAYF administrators.

If you have an integration with WAYF, either as a service provider or a user organisation, it is generally not necessary to change your local configuration at any point once the integration has been completed. However, on very rare occasions it is in fact necessary; and such an occasion is now approaching in the period leading up to spring 2026.

We are phasing out our current signing and encryption key pair and replacing that key pair with two new ones: one for signing and one for encryption. Online systems with login or logout traffic through WAYF need to know the public key in each key pair in order to validate signatures on traffic from WAYF and to XML-encrypt traffic to WAYF, respectively. If you have an integration with WAYF, you therefore now have the task of obtaining the new keys and configuring them in your WAYF setup – no later than 28 February 2026. Until then, both the old and the new keys will work; and the new ones are already in production, so you can switch already now – and should do so as soon as possible. Depending on which software you use towards WAYF, it may be necessary to configure WAYF’s new keys in your setup no later than 31 December 2025. Below we explain this in more detail and describe exactly what you need to do, depending on the type of integration you have with WAYF.

Why are we changing keys?

RSA-2048
REJECTED

Primarily to maintain the security associated with the keys' length. The keys in WAYF’s current RSA key pair are 2048 bits long, which is still considered sufficiently secure; but due to increasing attackcapability in the form of faster computers and improved algorithms, it has become the norm to use slightly longer keys, and our two new ones are each 3072 bits. Keys, however, become disproportionately slower to use the longer they are, which is why we are only now proceeding with the extension.

In theory, it can also be slightly more secure not to use the same key pair for both signing and encryption; therefore, at the same time we are introducing distinct key pairs for each purpose.

RSA-3072
ACCEPTED

By contrast, the key rotation is in no way about countering the possibility that the private key might have been stolen. That cannot have happened, and cannot happen with the new keys either, because all WAYF private keys are stored in an HSM. For that reason we only very rarely change keys – and we do not expect to change keys again until, in some years' time, the cryptographic algorithms themselves must be replaced with post-quantum algorithms.

Instead of lengthening RSA keys, one could of course achieve better security by moving away from RSA entirely and over to more secure algorithms and key types in the Elliptic Curve family. Unfortunately, this is not yet supported in most SSO software.

What this is not about

Before we proceed, for the sake of clarity we should point out two things that this article is not about.

The first is TLS certificates: the keys (and “certificates”) we are talking about replacing here have nothing to do with TLS. These are separate keys or X.509 objects operated on by the federation protocols (SAML and OIDC).

The second thing this article is not about is: the crypto keys your organisation itself generates and uses in its integrations with WAYF. This concerns only keys that originate from WAYF – and which you must configure in your WAYF integrations.

How do you start using the new keys?

Basically, you have to update your systems' metadata for WAYF. Below you can see what your organisation specifically needs to do to incorporate WAYF’s new crypto keys, depending on how your organisation participates in WAYF:

If your organisation is a user organisation in WAYF

If your organisation appears on the list here, it is a user organisation in WAYF. In that case, you do not need to do anything – unless your identity provider (“IdP”) encrypts its assertions to WAYF, or you are not sure whether your IdP software accepts having an SSO key with an expired date in the X.509 notAfter field as the only key in its configuration for a given service provider. Unfortunately, some IdP software treats SSO keys as actual certificates and enforces the expiry date written into the X.509 structure, despite this being disallowed according to the SAML interoperability profiles. If you have such software, you must update its WAYF configuration no later than 31 December 2025, because that is when WAYF's current “certificate” for signature validation and encryption “expires”. We recommend that in all cases, and as soon as possible, you update your IdP’s WAYF configuration – like this:

  • If the URL https://metadata.wayf.dk/wayf-metadata.xml appears in your WAYF configuration and your IdP is not an ADFS:
    • If you are sure your IdP regularly reads the URL automatically, you need do nothing.
    • Otherwise you must manually ensure that your IdP re-reads the URL. Prior to doing so, however, you must make sure this does not overwrite your present configuration for what attributes your software sends to WAYF.
  • Otherwise you must edit your IdP's WAYF configuration manually – like this:
    • Replace the value https://wayf.wayf.dk/module.php/saml/sp/saml2-logout.php/wayf.wayf.dk with the value https://wayf.wayf.dk/saml2/spslo3 [].
    • Quite possibly, your IdP has no keys at all configured for WAYF, and then you need do nothing about keys. But if it does hold keys for WAYF, you have to do the following:
      • If your WAYF configuration has an encryption key (“certificate”), you must replace that key with the value you get by clicking here: []. You can also obtain the new key as a file if your configuration requires it.
      • If your WAYF configuration currently has a key (“certificate”) for signature validation, you must add to your configuration the key you get by clicking here: []. You can also obtain the new key as a file if your configuration requires it.
    • If your IdP is an ADFS, make sure to switch off automatic updating of metadata.

If you do not have access yourself to edit the WAYF configuration in your organisation’s IdP, then you should ask your IT supplier to address the above and do whatever may be necessary.

Although your organisation primarily is a user organisation in WAYF, you should be aware that it may also be responsible for the WAYF configuration in one or more services receiving authentications from WAYF or specifically from your own IdP via WAYF (e.g. an instance of LinkedIn Learning, Zoom or TimeEdit). That is the case if it was you who originally set up SSO in the service or notified the service’s supplier of the WAYF SSO configuration. In that case, the yellow section below for service providers is unfortunately also relevant for you.

If you actually operate a service yourself, then you are of course responsible for updating the WAYF configuration in it; but it can also concern commercial services you have purchased, where the SSO configuration points to your IdP via WAYF (such as a Zoom instance or a learning management system). In each service of that kind you may have access yourself to edit the SSO settings, but otherwise you must draw the supplier’s attention to the service provider section below and have the supplier edit those settings on your behalf. If you do not have a complete overview of which services this concerns, then do not worry; the WAYF Secretariat can see and monitors which services are not yet using the new keys, and will contact the service owners continuously. Logging in to WAYF’s statistics service and seeing which services you use may also help to get an overview. The vast majority of these are managed by others; however, by reviewing the list you may be reminded which ones you are yourself responsible for configuring the SSO for.

Instances of Kaltura, Panopto and Zoom are, if nothing else had been agreed, handled by DeiC, who will edit the WAYF configuration in those. Also, the following services are already updated: Statens SSO, many instances of Pure and MoveOn, Arcanic services. TimeEdit is in the works.

Additional recommendations

We recommend that you use the federation as SSO for as many of your services as possible, e.g. SKI and Statens SSO. With exactly the same user experience as otherwise, using open standards developed within the international research and higher education community, this reduces integration work and ongoing maintenance, and enables you to rotate cryptographic keys – or even replace your entire login system towards services – without having to coordinate with each provider. Providers are all subject to the federation’s rules, including on interoperability, data minimisation and good IT practice. WAYF is part of the public sector and is first and foremost an association, and only secondarily a technical infrastructure. The WAYF Secretariat is happy to advise and assist, for example with getting SSO to work with new services. Make the most of your WAYF participation.

If your organisation is a service provider in WAYF

If your organisation, as a service provider, receives logins from one or more technical identity providers (“IdPs”) in WAYF, then you must for each IdP configuration you have in your technical service provider(s), do as explained below – as soon as possible and no later than 28 February 2026. If your SSO software (in violation of the protocol specification) does not accept SSO keys with an expired date in the X.509 notAfter field, then you must even do it no later than 31 December 2025; because that is when WAYF’s current “certificate” for signature validation and encryption “expires”. Unfortunately, some SSO libraries treat SSO keys as actual certificates and enforce the expiry date written into the X.509 structure, despite this being disallowed according to the SAML interoperability profiles. Because only the key matters, it also follows from the profile that a service must not base its signature validation on a fingerprint of the entire certificate that is included in each assertion, only on a fingerprint of the key itself. For each IdP configuration you have, you must do the following:

If the integration uses the SAML2 protocol

In that case, you will probably need to change your configuration a bit, depending on how it works:

If this still does not work afterwards, it may be because your system does not make use of all the information it has read from the URL. You must ensure that your system not only updates the crypto keys, but also the URLs it must contact WAYF on. It is a serious programming error if a system ignores elements of the SAML metadata it reads from its identity provider; this is not permitted, as the metadata document by specification is a complete recipe for how your system must communicate with the IdP. You can make the integration work again by completing a manual update as described below:
  • Otherwise (that is, if none of the URLs above are present, or your service provider is an ADFS), you must edit the IdP configuration manually – in one of two ways:
    • If your configuration contains URLs that include the string birk.php:
      • In each URL containing birk.php, you must replace birk.php with birk3 [].
      • You must replace the current signature validation key with the corresponding value from the document located at https://wayf.wayf.dk/MDQ/<domain>/idp/<domain>, where instead of <domain> you should insert, for example, cbs.dk for Copenhagen Business School, etc., i.e. the institution’s domain name. The value you need is the long string beginning with MII in the KeyDescriptor element with the XML attribute use set to signing.
    • Otherwise (if you do not have any URLs containing birk.php), proceed as follows:
    • If your service provider is an ADFS, be sure to switch off automatic updating of metadata.

    You are now finished. However, it is important that when performing a manual update you complete all steps and do not only update the key itself.

    If the integration uses the SAML2jwt facility

    If your integration uses WAYF’s special SAML2jwt facility, you must no later than 28 February 2026 implement the following two changes in your application:

  • And the key you have configured for WAYF must be replaced with the value you get by clicking here: []. You can also obtain the new key as a file if your configuration requires it.

    • However, WAYF wishes to phase out SAML2jwt and recommends that you switch to the more standardised protocol OIDC, which is very similar to SAML2jwt.

    If the integration uses the OIDC protocol

    Here we assume that your integration, if it needs crypto keys from WAYF, reads the relevant OpenID Provider configurations from WAYF dynamically and therefore obtains the new keys as needed. You therefore need do nothing. However, please contact the WAYF Secretariat immediately if, contrary to expectations, you experience problems during the key rotation period.

    Additional recommendations

    We recommend that you use WAYF for SSO with as many institutions as possible, including all relevant ones on the list here and in eduGAIN. This reduces work on both sides of the connection and provides more secure interoperability, using open standards developed within the international research and higher education community. We also recommend that where relevant you use the RA21 standard for signalling and activating institutional logins – which provides an optimal user experience and abstracts away from specific IDM suppliers at institutions. The standard is used, among other things, by the Danish Agency for Higher Education and Science. The WAYF Secretariat is happy to advise and assist. WAYF is part of the public sector and is first and foremost an association, and only secondarily a technical infrastructure. Make the most of your WAYF participation.

    If your organisation receives logins from Danish or Icelandic institutions through eduGAIN

    It is important that in each of your service providers (each of your SAML2 SPs) you update metadata from the eduGAIN federation that your SP is a member of. This might, for example, be the UK Access Management Federation, the German DFN-AAI, or the American InCommon – you will know which applies. But you must ensure that you update metadata from your federation before 1 January 2026, otherwise federated SSO from your Danish or NorthAtlantic customer institutions may stop working on that date. If your system (as it should) automatically updates metadata from your federation at regular intervals, then of course you need do nothing.

    If you do not read your Danish or Icelandic customer institution’s IdP metadata from your national federation, but instead from a URL the institution has given you (beginning with https://wayf.wayf.dk/MDQ/), then you can instead update the institution’s metadata from that URL – and you should do so before 1 January 2026. If your software complies with the rules for handling crypto keys in the SAML interoperability profiles, you may wait until 28 February 2026 to update metadata. If your system automatically updates metadata from the customer’s URL at regular intervals, you need do nothing.

    Tags: 
    nøgleskift
    rsa
    sso-nøgle
    kryptonøgle
    saml
    oidc