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 Establish That a Site Is Trustworthy
HTTPS proves that a browser has established an encrypted connection to a server presenting a valid certificate for some domain. It does not prove the site’s intent, business legitimacy, or content safety. A fraudster can still obtain a certificate for a deceptive domain and serve a fully encrypted phishing page that looks convincing to users.
What a Valid Certificate Actually Confirms
The real security value of HTTPS is confidentiality and integrity in transit. It protects against passive interception and tampering between the browser and the server, which is important, but narrow. The browser is checking transport security and certificate validity, not whether the organisation behind the page is honest or whether the page is safe to trust with credentials or payments.
That distinction matters because many users treat the padlock as a site endorsement. In practice, certificate issuance and domain control are far easier to obtain than genuine trustworthiness. This is why phishing sites, cloned login portals, and scam storefronts can still look “secure” when they are only securely delivering fraudulent content.
How False Trust Changes User Behaviour and Control Effectiveness
When people equate HTTPS with safety, they are more likely to click, sign in, and approve actions without additional verification. That shifts the problem from transport security to human trust exploitation. A strong visual cue can suppress healthy scepticism, which is exactly what attackers want when they are steering victims toward credential entry, MFA prompts, or financial transfer pages.
At an organisational level, this weakens awareness training if the message is too simplistic. “Look for the padlock” is not a safe decision rule. The safer rule is to verify the domain, the sender, the business context, and the expected workflow before entering credentials or approving any sensitive action.
Risk and Threat Considerations
Relying on HTTPS alone creates a trust shortcut that attackers can exploit with minimal technical sophistication. The encrypted connection may be genuine while the site’s purpose is malicious, so users can be led into credential theft, account takeover, or fraudulent transactions under a false sense of safety.
Failure mechanism: the defender treats certificate validity as proof of legitimacy, while the attacker uses a valid domain and HTTPS to make a phishing page, clone portal, or scam workflow appear trustworthy.
Impact: reduced user scrutiny, higher phishing success rates, easier credential capture, and a weaker first line of defence at the point of click.
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 OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant identity guidance addresses the gap between encrypted transport and trustworthy authentication. |
| Recommendation — Prefer phishing-resistant authenticators and verify the site origin before accepting credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticator Management | The issue is mistaken trust in a protected channel rather than identity assurance, so authentication controls must be explicit. |
| Recommendation — Enforce authenticator checks that do not rely on HTTPS as proof of site legitimacy. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Federated login flows are a common place where users can confuse secure transport with trustworthy identity. |
| Recommendation — Validate issuer and redirect expectations before trusting a login flow. | ||
| MITRE ATT&CK | T1566 — Phishing | Valid HTTPS is frequently used to make phishing infrastructure appear credible to victims. |
| Recommendation — Map phishing pages that use valid certificates to T1566 and hunt for lookalike domains. | ||
Practitioner Guidance
What to verify: Train users and support teams to verify the domain, brand context, and request path, not the padlock alone. A secure connection is only meaningful when it matches an expected destination and an expected action.
Decision rule: If a page asks for credentials, MFA approval, payment details, or session re-authentication, treat HTTPS as a transport control, not as a trust decision. Add out-of-band verification or stronger site reputation checks before sensitive submission.
What good looks like: Awareness material should teach “encrypted does not equal authentic” and reinforce domain recognition, bookmark use, and phishing reporting. The best control outcome is when users slow down at the moment of entry, not when they notice the padlock.
Practitioner takeaway: HTTPS is necessary for secure transport, but it is never sufficient evidence that a website deserves trust. The control objective is to verify identity and intent separately from encryption.
Related resources from NHI Mgmt Group
- What breaks when organisations treat HTTPS or a trusted-looking website as proof of legitimacy?
- 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?
- What happens when organisations rely on passwords alone instead of layered account security?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
