Topic starter
24/06/2026 11:12 pm
TL;DR: Chrome’s “Not Secure” warning flags pages served over HTTP because the connection is unencrypted and unauthenticated, leaving content and submitted data exposed to interception or tampering, according to DigiCert. The governance lesson is simple: browser warnings are a symptom of broken transport trust, not a site malware signal.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “Seeing a “Not Secure” Warning in Chrome? Here’s Why and What to Do about It”.
Key questions
Q: How should organisations handle websites that still show a browser not secure warning?
A: They should move the entire site to HTTPS, not just the login page.
Q: Why does HTTP create risk for websites that collect logins or payment details?
A: HTTP leaves the browser and web server connection unencrypted, so data can be intercepted in transit.
Q: What breaks when HTTPS is only deployed on part of a website?
A: Partial deployment creates inconsistent assurance.
Practitioner guidance
- Enforce HTTPS by default Make HTTPS the default for every page, including login forms, account settings, and any flow that accepts personal or payment data.
- Validate certificate coverage across the whole site Check that the certificate chain covers all hostnames and subdomains in use, and confirm that mixed secure and insecure pages do not remain reachable through legacy URLs.
- Redirect all HTTP traffic to secure endpoints Use permanent redirects and server-side enforcement so visitors arrive on HTTPS automatically, even when they type or bookmark an HTTP URL.
Bottom line: Chrome’s warning is telling users that the connection, not necessarily the site content, is unsafe because HTTP provides no encryption or authentication.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 7:56 am
Secure transport is an identity control, not just a website setting. When authentication, form submission, or payment traffic moves over HTTP, the organisation has already lost confidentiality and integrity before any downstream control can help. The browser warning is therefore a control failure indicator, not a cosmetic UX issue. For practitioners, HTTPS belongs in the same governance conversation as login policy and session protection.
A question worth separating out:
Q: How should security teams decide whether a browser warning is acceptable?
A: A browser warning is only acceptable on content that carries no sensitive data and no identity-relevant interaction. If the page supports authentication, form submission, or any transaction involving personal information, the warning indicates a control gap that should be fixed. Security teams should treat secure transport as a baseline requirement, not a discretionary feature.
👉 Read our full editorial: Chrome’s not secure warning exposes the limits of HTTP trust