They should move the entire site to HTTPS, not just the login page. The warning indicates that the browser cannot protect the connection, so any data submitted on that path may be exposed or altered in transit. Redirect all HTTP traffic, remove mixed content, and ensure secure transport is enforced by default.
Why This Matters for Security Teams
A browser not secure warning is not a cosmetic issue. It means the site is failing to provide authenticated, encrypted transport, so credentials, session tokens, form data, and page content may be exposed or altered in transit. Security teams should treat it as a site-wide trust failure, not a login-only defect. That matters even more when users may reuse passwords or submit sensitive details on pages that appear routine. The broader governance lesson matches NIST Cybersecurity Framework 2.0: protect the asset by default, not only the highest-risk transaction path.
The practical risk is that warnings often surface after search indexing, embeds, redirects, or legacy content have already leaked trust signals to visitors. NHIMG research on the Ultimate Guide to NHIs shows how often organisations underestimate exposure until damage is visible, especially where credentials and secrets are already spread across many systems. In practice, many security teams encounter browser warnings only after customers or browsers block key workflows, rather than through intentional hardening.
How It Works in Practice
The correct fix is to move the entire site to HTTPS and enforce it everywhere. That means every page, asset, API call, redirect, and embedded resource must be served over TLS so the browser can verify the site and protect the session. A partial fix, such as securing only the login form, still leaves users vulnerable on other pages and can break trust in the whole domain. Guidance from the NIST Cybersecurity Framework 2.0 aligns with this approach: secure communications should be systematic, not selective.
- Install a valid certificate for the full hostname set, including subdomains that users actually reach.
- Redirect all HTTP traffic to HTTPS with permanent redirects where appropriate.
- Enable HSTS once HTTPS is stable, so browsers stop trying insecure fallback paths.
- Remove mixed content, including scripts, images, fonts, and third-party embeds loaded over HTTP.
- Update canonical URLs, sitemaps, and application settings so new links are generated with HTTPS by default.
- Test API endpoints and backend services as well, since browser warnings often coexist with insecure service-to-service calls.
NHIMG’s research on Schneider Electric credentials breach reinforces a common pattern: once weak transport or exposed secrets are present, attackers do not need much time to exploit the gap. Organisations should also review certificate renewal, redirect chains, and CDN or load balancer settings so the fix survives infrastructure changes. These controls tend to break down when legacy applications still hard-code HTTP endpoints, because the browser may show the site as insecure even after the main page appears to load correctly.
Common Variations and Edge Cases
Tighter transport control often increases operational overhead, requiring organisations to balance user trust and data protection against migration effort and legacy compatibility. That tradeoff is especially visible on older sites, staging environments, and third-party hosted pages that were never built with HTTPS-first delivery in mind. Best practice is evolving, but the direction is clear: exceptions should be temporary and documented, not treated as acceptable steady state.
There are a few edge cases to handle carefully. Internal-only sites sometimes escape notice because they are behind a VPN, but browsers still warn if transport is insecure. Mixed content can also make an otherwise valid HTTPS site appear broken, so teams should test the full page render rather than only the landing URL. For organisations that rely on external embeds, payment widgets, or analytics tags, the browser warning may persist until those dependencies are upgraded too. The most common failure mode is forgetting that one insecure subresource can undermine the security posture of the entire page.
For teams modernising older estates, the safest sequencing is to fix certificates, enforce redirects, remove mixed content, and then validate the result in production-like browsers. If user-facing content still needs special handling, it is better to isolate it on a secure subdomain than leave the main domain partially exposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-2 | Addresses protecting data in transit, which is the core issue behind browser not secure warnings. |
| OWASP Non-Human Identity Top 10 | Relevant where insecure transport exposes secrets, tokens, or API keys carried by web sessions. | |
| NIST AI RMF | GOV | Governance is needed to enforce secure defaults across web properties and legacy exceptions. |
Enforce encrypted transport for every page and asset, not just login flows, and verify it remains on by default.
