They create a false trust boundary. Attackers can still use valid SSL certificates on fraudulent sites, so encryption does not confirm identity or intent. When users assume HTTPS means safe, phishing pages become more effective, credential theft becomes easier, and security awareness controls lose much of their value at the point of click.
Why HTTPS Alone Cannot Prove a Site Is Safe
HTTPS tells you the connection is encrypted and that a certificate was presented for a domain, but it does not tell you whether the site is legitimate, trustworthy, or intended to help the user. A convincing phishing page can still be served over TLS, which means the browser lock icon can become a false signal if people treat transport security as proof of business authenticity.
The practical failure is that users and even some controls collapse two different questions, “Is the channel protected?” and “Is this destination safe?”. Those are not the same. Encryption protects the path, not the motive, reputation, or authorization of the operator behind the site.
How Attackers Exploit the Trust Signal
Phishing is more effective when the browser looks reassuring, because the visual cue reduces hesitation at the point of click. Attackers can obtain valid certificates for domains they control, so a padlock or HTTPS prefix can coexist with credential harvesting, account takeover attempts, and other fraud.
That matters because trust cues are often used as a fast decision shortcut. When the shortcut is wrong, users are more likely to enter passwords, MFA codes, session data, or recovery details into a malicious form. The site may be cryptographically sound while still being operationally hostile.
For a broader view of how deceptive trust cues and credential abuse appear in real attack chains, see the MITRE ATT&CK Enterprise Matrix for credential access and related adversary behaviour. Stronger login assurance also helps, which is why phishing-resistant authentication guidance in NIST SP 800-63 Digital Identity Guidelines is so relevant when users may be steered toward lookalike sites.
What Organisations Should Rely On Instead of the Padlock
Security teams should treat HTTPS as one layer, not a trust verdict. Safer judgments come from combining domain reputation, brand monitoring, lookalike-domain detection, email and web filtering, user education, and strong authentication that is resistant to replay and phishing.
Controls should also be designed around the fact that users make rapid decisions under limited attention. Clear branding, safe-link handling, and explicit verification steps for high-risk workflows help more than telling people to “look for HTTPS”. If the user cannot tell whether the site is expected, owned, and authorized, the padlock should not be allowed to carry that burden alone.
Current identity and access guidance also supports verifying the authenticator rather than trusting the transport alone. NIST Cybersecurity Framework 2.0 is useful here because it frames governance, protection, and detection as separate functions, while NIST SP 800-53 Rev 5 Security and Privacy Controls gives practitioners a control basis for access control, identification, authentication, monitoring, and awareness.
Risk and Threat Considerations
Relying on HTTPS alone creates a trust gap that attackers can exploit at very low cost. The threat is not broken encryption, it is the misuse of a valid security signal to make a fraudulent destination appear safe enough for users to disclose secrets or approve risky actions.
Failure mechanism: The organisation treats certificate validity as proof of site legitimacy, so phishing pages and other fraudulent destinations inherit a credibility boost that normalises unsafe user behaviour.
Impact: Credential theft, session compromise, and reduced effectiveness of awareness training become more likely because the user interface itself is helping the attacker.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1556 — Adversary-in-the-Middle | Valid HTTPS can still support phishing and credential capture via deceptive destinations. |
| Recommendation — Map fake login flows to credential access techniques and tune detections for phishing-driven theft. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication guidance directly addresses unsafe reliance on site appearance. |
| Recommendation — Adopt phishing-resistant authenticators for sensitive logins and recovery flows. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | The question is about trusting a site, so authentication and access assurance must extend beyond transport encryption. |
| Recommendation — Require stronger authentication assurance for high-risk web interactions. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Users must be authenticated through controls stronger than the presence of HTTPS alone. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Phishing over HTTPS is often detected through logs and review of suspicious sign-in activity. | |
| Recommendation — Enforce strong user authentication before sensitive actions or account access. Review authentication logs for anomalous login attempts and credential misuse. | ||
Practitioner Guidance
What to verify: Test whether users can distinguish encrypted transport from verified destination. If people routinely equate the lock icon with trustworthiness, your awareness programme and web controls are not aligned with how the attack actually works.
Decision rule: For any workflow that collects credentials, recovery data, payment details, or privileged approvals, require an additional trust check beyond browser encryption, especially when the user arrives by link rather than by known navigation.
Practitioner takeaway: HTTPS is necessary for confidentiality in transit, but it is never sufficient as a safety decision, so the control objective is to verify destination, context, and authenticity before the user acts.
Related resources from NHI Mgmt Group
- What breaks when organisations treat HTTPS or a trusted-looking website as proof of legitimacy?
- What happens when security teams rely on integration alone instead of contextualised AppSec analysis?
- What happens when organisations rely on SAST alone for modern application security?
- What happens when organisations rely on training alone instead of adaptive controls for high-risk users?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org