TLS Configuration Ratings of Norwegian Banks
Norwegian banks present an interesting cross-section of TLS deployment quality: a small market with regulatory oversight, technical teams that generally take security seriously, but infrastructure that spans from modern cloud-native deployments to legacy systems that move more slowly. This page documents TLS configuration observations across a selection of Norwegian banking sites — internet banking portals, authentication endpoints, and public-facing corporate sites — covering the rating methodology, specific cipher suite and protocol version choices, certificate handling, and the patterns that distinguish strong from weak configurations. The findings are based on analysis using publicly available TLS scanning tools against production HTTPS endpoints. This page sits within the security section and connects to the privacy and security topic hub.
Rating methodology
The analysis used Qualys SSL Labs ratings as the primary scoring framework, supplemented by direct inspection of cipher suites and certificate details using openssl s_client and testssl.sh. The Qualys A+/A/B/C/F grade framework provides a consistent baseline: A+ requires HTTP Strict Transport Security with a long max-age, forward secrecy on all cipher suites, and no weak protocols; A requires the same minus HSTS; B typically indicates use of TLS 1.0 or 1.1 support or a weaker cipher suite configuration; C and below indicate significant configuration problems.
Qualys SSL Labs grades are reproducible and widely understood, making them a useful common reference, but they do not capture everything that matters. The supplementary analysis examined: cipher suite ordering (whether strong suites were correctly prioritised), HSTS preloading status, HTTP-to-HTTPS redirect handling, certificate transparency logging, and OCSP stapling. These aspects are graded by SSL Labs but not always emphasised in the summary rating.
What Norwegian banks typically get right
The baseline TLS hygiene at Norwegian banking sites is generally good. The regulatory environment — Financial Supervisory Authority of Norway (Finanstilsynet) requirements, plus general GDPR exposure — creates pressure to maintain configurations that at minimum pass routine security audits.
The majority of Norwegian banks' internet banking portals tested at A or A+ on Qualys SSL Labs during analysis. TLS 1.0 and TLS 1.1 support had been almost universally disabled — findings that were not universal five years earlier but have become standard. Certificate chains were consistently complete: no sites presented incomplete chains that required browsers to chase intermediate certificates. Extended Validation certificates were common on the primary internet banking hostnames, though less common on subsidiary services and API endpoints. Certificate lifetimes were within industry norms, generally 90 days (Let's Encrypt automated) or one-to-two years for commercially issued EV certificates.
Certificate transparency is another area where Norwegian banks performed well. All tested hostnames presented SCTs (Signed Certificate Timestamps) from multiple CT logs, either embedded in the certificate, delivered via OCSP, or delivered via TLS extension. This is expected for any certificate issued after 2018, when Chrome mandated CT for all publicly trusted certificates, but it is worth noting because CT compliance was not universal in the earlier dataset.
Where they commonly underperform
The consistent weak points are not in the fundamentals but in the configuration details that matter for modern TLS security.
The most common rating-limiting issue across Norwegian banking sites is HSTS configuration. Many sites had HSTS headers with max-age values that were either too short (30 days or 90 days rather than the one-year minimum for A+ rating and preloading eligibility) or missing the includeSubDomains directive. A banking site with a short HSTS max-age is not meaningfully less secure day-to-day, but it represents a misconfiguration that reduces protection during certificate transitions and creates a window for HTTPS downgrade attacks that a properly configured HSTS policy would prevent.
OCSP stapling is a second recurring gap. OCSP stapling — where the server fetches and caches the certificate revocation status and includes it in the TLS handshake — improves both performance and privacy (clients do not need to contact the CA's OCSP responder during the handshake). Several tested sites either had OCSP stapling disabled or non-functional. This does not affect the Qualys grade directly but is visible in the detailed report and matters for users on high-latency connections where an OCSP round-trip during handshake is measurable.
Cipher suite analysis
Modern TLS configuration best practice prioritises AEAD cipher suites — specifically AES-GCM and ChaCha20-Poly1305 — and ensures forward secrecy through ephemeral key exchange (ECDHE, DHE). TLS 1.3, which mandates AEAD and forward secrecy, simplifies this considerably; correctly enabling TLS 1.3 and disabling TLS 1.2 legacy cipher suites covers most of the surface.
Norwegian banking sites cannot in practice drop TLS 1.2 support entirely — a non-trivial segment of their user base runs software that does not support TLS 1.3. Older banking application integrations, corporate proxy infrastructure, and some enterprise certificate management systems are TLS 1.2 only. For this reason, observed configurations retained TLS 1.2 with a curated cipher suite list rather than mandating TLS 1.3-only. The practical floor for a well-configured Norwegian bank TLS deployment is: TLS 1.3 preferred, TLS 1.2 supported with ECDHE+AES-GCM cipher suites only, RC4 and 3DES cipher suites absent, no CBC-mode cipher suites in TLS 1.2.
The presence of legacy cipher suites is a consistent differentiator between strong and average configurations. Sites with B ratings were typically there because they retained cipher suites with CBC mode in TLS 1.2 for compatibility reasons, or because they had not refreshed their cipher suite list to remove suites that were valid several years ago but are now considered below the acceptable floor.
Certificate handling
Norwegian banks circa 2017–2019: The dominant pattern was commercially issued OV (Organisation Validation) or EV (Extended Validation) certificates with two-year lifetimes from major CAs. Let's Encrypt was viewed with some scepticism in financial services — the domain-validation only model and short 90-day lifetimes were perceived as unsuitable for high-assurance banking contexts. Most banks had manual certificate management processes, leading to occasional near-expiry events.
Current pattern (2024–2026): The picture is more segmented. Primary internet banking portals and authentication endpoints typically still use commercially issued EV or OV certificates from DigiCert, Sectigo, or equivalent CAs, with automated renewal. Subsidiary services, API endpoints, internal tooling, and less visible hostnames increasingly use Let's Encrypt via automated ACME clients — a significant shift driven by the operational convenience of automation. The 90-day Let's Encrypt lifetime forces automation; manual management of Let's Encrypt certificates is not operationally sustainable at scale.
The deprecation of extended validation certificate UI treatment in Chrome (version 76, 2019) and Firefox removed the green address bar that had been a defining feature of EV certificates for banking sites. Browsers now display EV and DV certificates identically in the URL bar. This removed a key differentiator that had justified the higher cost and manual management overhead of EV certificates for many organisations. Since the UI treatment disappeared, the financial services industry has progressively moved toward DV certificates where EV was previously mandated by internal policy.
The broader pattern
Norwegian banks are a reasonable proxy for financial services TLS configuration in a mid-sized, technically sophisticated European market. The strong points — complete certificate chains, CT compliance, TLS 1.0/1.1 disabled, generally correct cipher suite selection — reflect regulatory pressure and active security team involvement. The weak points — inconsistent HSTS configuration, patchy OCSP stapling, retained legacy cipher suites — reflect the practical friction of maintaining configuration across heterogeneous infrastructure without breaking compatibility for the full user population.
The gap between a well-configured site (A+) and an average site (A or B) in this analysis is rarely about fundamental security failures. It is about configuration precision: the difference between a max-age of 365 days and one of 31536000 (same value, different presentation in policy), between enabling OCSP stapling and leaving it at default, between reviewing the cipher suite list annually and leaving it unchanged from the original deployment. These details compound: a site that scores A on each individual metric but misses the A+ threshold on three of them ends up with an overall configuration that is measurably weaker against specific attack scenarios than it needs to be.
For the certificate management side of TLS deployment, the Let's Encrypt and dual-stack experiences page covers the practical operational considerations.