What should organisations teach users to look for when a phishing page uses HTTPS?

Organisations should teach users that HTTPS means the connection is encrypted, not that the site is safe or legitimate. Users should check the full domain, be cautious with unexpected login prompts, avoid entering credentials from unsolicited messages, and report anything that looks unusual. That simple habit reduces the chance that a padlock icon will override judgement.

What HTTPS Does, and What It Does Not Prove

Teach users to treat HTTPS as a transport feature, not a trust verdict. The padlock only shows that the browser has an encrypted connection to the server it reached; it does not confirm that the website is legitimate, well run, or safe to use. Phishing pages routinely use valid TLS certificates, so the visible security indicator can be present on a malicious site.

The practical lesson is that users should verify the destination, not the decoration. A page can look polished, show HTTPS, and still be a counterfeit login flow built to collect credentials or session data. For that reason, the full domain, spelling, and context of the request matter more than the padlock icon.

Users should also understand that phishing often works by creating urgency and pushing them past normal verification habits. A secure connection does not reduce the need to pause, inspect the URL, and ask whether the login prompt was expected in the first place. That distinction is what turns a browser indicator into a teachable moment instead of a false reassurance.

Train users to check the complete domain name, especially the registered domain and any unexpected subdomains. Small changes, such as extra words, hyphens, lookalike characters, or an unfamiliar brand domain, are often the giveaway that the page is not the real service. The same rule applies when a page claims to support a known brand but the URL does not match the organisation’s normal login path.

They should also treat unexpected credential prompts as a warning sign, even when the page is HTTPS protected. If a link in email, chat, or a text message sends them to a sign-in form they did not initiate, the safest assumption is that the request deserves verification through a separate channel. That habit is more reliable than trying to judge safety from the padlock alone.

When a page asks for a password, MFA code, or recovery detail after an unsolicited message, users should stop and validate the request from a trusted bookmark, the organisation’s official app, or a known support channel. This is especially important because phishing pages are designed to mimic normal authentication steps closely enough that users may not notice the handoff into an attacker-controlled flow.

How Organisations Should Reinforce the Right Behaviour

Security awareness should focus on recognition, not just warning labels. Users need repeated examples of real phishing pages that use HTTPS so they learn that encrypted transport and site legitimacy are separate issues. The goal is to build a simple decision rule: if the request is unexpected, inspect the source first and enter credentials only after independent verification.

It also helps to give users a concrete reporting path for suspicious login pages. If they can report an odd sign-in screen quickly, security teams can review the URL, block copies, alert other users, and determine whether the page is part of a broader campaign. That feedback loop matters because phishing is often time-sensitive and scale amplifies the impact of a single missed click.

Organisations should make the safe behaviour easy to perform. Bookmarked portals, password managers that match on the correct domain, and clear guidance on approved login URLs reduce reliance on visual cues that attackers can imitate. The stronger the normal workflow, the less likely a user is to treat HTTPS as the deciding factor.

Risk and Threat Considerations

Phishing pages with HTTPS are dangerous because they exploit a false sense of safety. The encrypted connection can make the page look more trustworthy while the real attack is happening at the application and brand-trust level, where users are persuaded to submit credentials, MFA codes, or recovery information to an attacker-controlled site.

Failure mechanism: The attacker registers a plausible domain, obtains a valid certificate, and presents a login page that mirrors the legitimate service closely enough that the browser’s padlock appears reassuring while the victim enters secrets into the wrong destination.

Impact: Users may disclose credentials or one-time codes, enabling account takeover, session abuse, downstream fraud, or access to internal services that trust the compromised account.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5, CIS Controls v8, OWASP ASVS and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	HTTPS phishing targets organizational credentials and login trust.
	IA-8 — Identification and Authentication (Non-Organizational Users)	Phishing pages often impersonate external or customer-facing sign-in flows.
	AU-2 — Event Logging	Suspicious login-page reports and access attempts need traceable evidence.
Recommendation — Train users to verify the login destination before entering organizational credentials. Apply stronger verification for external-user login pages and branded sign-in portals. Log suspicious authentication events so phishing reports can be investigated quickly.
ISO/IEC 27001:2022	A.6.3 — Information security awareness, education and training	User training is the primary control against HTTPS-based phishing deception.
	A.5.24 — Information security incident management planning and preparation	Users need a clear process for reporting suspected phishing pages.
Recommendation — Teach users to verify domains and treat unexpected login prompts as suspicious. Provide a simple reporting path for suspicious login pages and capture the URL.
CIS Controls v8	CIS-14 — Security Awareness and Skills Training	HTTPS phishing is a user-judgement problem best addressed through awareness training.
Recommendation — Include examples of valid-HTTPS phishing in awareness training and testing.
OWASP ASVS	V10 — OAuth and OIDC	Modern phishing pages often mimic federated sign-in and token capture flows.
Recommendation — Validate that users are redirected only to approved identity-provider domains.
NIST CSF 2.0	PR.AT-01 — Employees are informed and trained	Users must be trained to interpret HTTPS correctly and spot phishing cues.
	DE.CM-09 — Network Monitoring	Monitoring and reporting suspicious sign-in pages supports early detection.
Recommendation — Train users to verify the domain and request context before submitting credentials. Use monitoring and user reports to detect phishing campaigns quickly.

Practitioner Guidance

What to prioritise: Teach users one verification habit that beats visual trust signals, check the full domain and the source of the request before entering anything sensitive. That rule is more effective than asking users to interpret certificate indicators or browser icons.

What to verify: Confirm that training and anti-phishing guidance include examples of https phishing, not just obviously broken sites. If users only see fake pages with poor visuals, they will overestimate the value of the padlock when faced with a polished attack.

Common mistake: Treating HTTPS as a legitimacy check instead of a transport check. The correct judgement is that encrypted traffic can still carry a fraudulent page, so trust must come from the destination and context, not the lock icon.

Practitioner takeaway: The key control is behavioural discipline, users should learn to distrust unexpected login prompts until the domain and request path are independently verified.