HTTPS only shows that the connection is encrypted and the certificate matches the domain, not that the site owner is legitimate or safe. Attackers can obtain valid certificates for malicious domains and build convincing phishing pages. Teams should still check domain reputation, content, and login prompts before trusting a site or entering credentials.
Why HTTPS can be genuine and still not trustworthy
https proves that the browser established an encrypted connection to a domain that controls a valid certificate for that domain. It does not prove the operator is legitimate, that the site is safe, or that the content is truthful. A malicious actor can run a convincing phishing site on a domain they control and still present a perfectly valid HTTPS indicator.
That distinction matters because the trust signal is technical, not reputational. The certificate confirms domain control and transport protection, but it says nothing about intent, business legitimacy, or whether the page is designed to capture credentials or payment details. A secure connection can therefore protect you while delivering you straight to a fraudulent destination.
For that reason, the phishing guide is often the better reference point than the padlock icon alone, because phishing frequently combines lookalike domains, convincing branding, and credential prompts that appear inside a fully encrypted session.
What attackers can do with a valid certificate
Attackers do not need to break TLS to abuse user trust. They can register a domain that resembles a real brand, obtain a certificate through automated issuance, and then host a page that mimics the target well enough to trick users into entering passwords, MFA codes, or payment data. The browser will still show HTTPS if the connection is encrypted and the certificate checks out for that domain.
This is why HTTPS should be treated as one control among many, not as proof of site legitimacy. The real security question is whether the destination is expected, whether the domain is genuine, and whether the page behavior matches the normal workflow for that service. Content quality, domain age and reputation, and the presence of unexpected login prompts matter more than the presence of a lock icon.
When a suspicious site is trying to collect credentials through a valid certificate, the attack path is usually social rather than technical. The site borrows trust from the browser chrome, not from the legitimacy of the organisation behind the page.
What to verify before entering credentials
Check the domain carefully, especially for subtle misspellings, added words, unusual subdomains, and internationalised characters that resemble the real brand. Then compare the site’s purpose with your expectation: if you were not actively navigating to a login page, payment page, or account recovery flow, pause before entering anything sensitive.
Also inspect the page context. Unexpected urgency, generic branding, poor grammar, or a login box appearing where no login should exist are all signs that the site may be trying to harvest secrets rather than provide a service. If the site is asking for credentials, the burden is on the page to justify why that prompt belongs there.
For teams that want a broader defensive baseline, the browser and endpoint should support more than one trust check. NIST SP 800-63 Digital Identity Guidelines is useful here because phishing-resistant authentication reduces the value of credential capture even when a user lands on a convincing fraudulent site.
Risk and Threat Considerations
HTTPS can create a false sense of safety when users equate encryption with legitimacy. That misconception is valuable to attackers because it lowers suspicion at the exact moment a victim is being asked to disclose a password, token, or payment detail.
Failure mechanism: The attacker secures the transport layer, but abuses the human trust signal attached to the padlock and certificate. A valid certificate does not stop a lookalike domain from presenting a convincing phishing page or harvesting secrets once the user arrives.
Impact: Credentials, sessions, and other sensitive inputs can be handed to an untrusted operator while the browser still appears secure. That can lead to account takeover, downstream fraud, or further compromise if the stolen access is reused elsewhere.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | 5.1 — Authenticator Assurance and Phishing Resistance | HTTPS can still deliver users to phishing pages, so phishing-resistant auth materially reduces credential theft risk. |
| Recommendation — Prefer phishing-resistant authenticators for login flows that attackers can imitate. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Trustworthy login decisions depend on strong user authentication, not transport encryption alone. |
| Recommendation — Require strong authentication for user-facing systems that handle credentials. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The page can be secure in transit while still abusing authentication prompts and credential capture patterns. |
| Recommendation — Validate authentication flows to prevent credential harvesting and impersonation abuse. | ||
| MITRE ATT&CK | T1566 — Phishing | HTTPS is commonly used to make phishing pages appear more trustworthy to victims. |
| Recommendation — Detect and disrupt phishing infrastructure that relies on trusted-looking web delivery. | ||
Practitioner Guidance
What to prioritise: Treat domain verification and content inspection as the real trust decision, not the HTTPS indicator. If the destination is unexpected, request the user to navigate from a known bookmark or approved portal rather than from a link in an email, message, or ad.
What to verify: Confirm that the login prompt, payment form, or account recovery flow is consistent with the organisation you think you are reaching. If the site is asking for credentials in a context that does not fit the user journey, assume the page is untrusted until proven otherwise.
Practitioner takeaway: HTTPS protects the channel, not the identity or intent of the site owner, so trust decisions must combine certificate status with domain, context, and user-flow validation.
Related resources from NHI Mgmt Group
- How should organisations prove that regulated reporting data is trustworthy?
- What breaks when HTTPS is only deployed on part of a website?
- How do security teams prove software is trustworthy to auditors and boards?
- How can organisations prove their AppSec programme is still trustworthy when AI tools are added?
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 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org