The network wants to promote the use of strong cipher suites with minimum discomfort for end-users. Those roles that are in direct contact with their customers (e.g. a HM with it's DV's and an AD/MR with its users) are allowed to tighten security based on their risk analysis.

All communication between peers in these specifications is based on HTTP. All communication MUST be secured using Transport Layer Security, TLS. As a result, all communication MUST be transported over HTTPS (

For HTTPS and TLS, any implementation MUST take the recommendations in BCP195 ( and the latest version of the NCSC-security guidelines for TLS-usage (currently The following requirements are applicable for this specification in relation to the NCSC guidelines:

  • For back-channel communication, the guidelines categorized as "good" MUST be applied.
  • For front-channel communication, the guidelines for "good" MUST be applied and the guidelines for "sufficient" MAY be applied, depending on target audience and support requirements.
  • Guidelines categorized as "insufficient" MUST NOT be applied and those categorized as "phase out" SHOULD NOT be used.

As HTTP itself is stateless, implementations are free to choose a method of maintaining state or sessions with a User-agent when applicable. The following applies for any HTTP state/session mechanism:

  • HTTP servers MUST ensure session and state information is secured and User-agents are properly instructed with relevant security settings (e.g. proper cookie lifetime, Secure setting for cookies, CORS headers and similar).
  • Any HTTP session or state tracking mechanisms MUST be implemented using current best practices to avoid session hijacking and other attacks. For more information, see for instance

  • No labels