Notifications
Clear all
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.
NHIMG editorial — based on content published by DigiCert: Seeing a “Not Secure” warning in Chrome? Here’s why and what to do about it
Questions worth separating out
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 do insecure web pages matter to identity and access management?
A: Identity controls depend on a trustworthy transport layer.
Q: What breaks when HTTPS is only deployed on part of a website?
A: Partial deployment creates inconsistent assurance.
Practitioner guidance
- Force HTTPS across the full user journey Redirect every HTTP request to HTTPS by default, including landing pages, help pages, and form flows.
- Audit mixed-protocol paths before they reach users Map every page, API endpoint, and embedded resource that still loads over HTTP.
- Deploy certificates and session protections together Pair TLS certificate rollout with HSTS, secure cookies, and consistent session handling so the browser can enforce the secure path automatically.
What's in the full article
DigiCert's full article covers the operational detail this post intentionally leaves for the source:
- Browser-specific examples showing how Chrome, Safari, and Firefox present insecure pages.
- Step-by-step guidance for site owners on choosing and installing the right TLS/SSL certificate.
- Practical visitor guidance for dealing with pages that still load over HTTP.
- Explanations of why some pages on a site may be secure while others still trigger the warning.
👉 Read DigiCert’s explanation of Chrome’s not secure warning and HTTPS fixes →
Chrome’s not secure warning: what IAM and security teams should do?
Explore further
25/06/2026 7:56 am
Transport trust is a prerequisite for identity trust. When a browser warns that a page is not secure, the site has already lost the assurance that user data will remain confidential and unchanged in transit. That matters to identity programmes because authentication, session handling, and privileged workflows all depend on a trustworthy channel. If the transport is exposed, the identity control stack starts from a compromised assumption, and practitioners should treat that as a governance failure, not a browser annoyance.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- A further 47% have only partial visibility, which leaves most identity programmes unable to see the full trust chain before access is granted.
A question worth separating out:
Q: Who is accountable when a site exposes users to unencrypted browsing?
A: The website owner and operator are accountable for providing a secure transport path. Visitors cannot fix the issue locally, because the browser warning reflects how the site is served. Governance should therefore treat HTTPS coverage as an operational responsibility, not a user preference.
👉 Read our full editorial: Chrome’s not secure warning exposes the limits of HTTP trust
