How can people verify that a website is really the one they intended to reach?

Do not stop at the padlock icon. Click it and inspect the digital certificate so you can confirm the site is presenting valid identity information for the organisation you expect. This matters because fraudulent domains can also use SSL certificates, so visual trust cues alone are not enough to prove authenticity or safety.

What the certificate tells you that the padlock does not

The padlock is only a starting signal. The certificate is what tells you which organisation, domain, or service is actually presenting identity information to your browser, and whether that identity chains to a trusted issuer. A valid certificate does not guarantee the site is safe, but it does help you test whether the site is claiming to be the organisation you intended to reach.

That matters because modern browsers are built to show a secure transport indicator even when the human expectation behind the visit is wrong. The practical check is not “is there encryption,” but “does the certificate identity match the destination I meant to visit?”

How to inspect the certificate in a way that is useful

Open the browser’s certificate details from the padlock or site information panel and compare the subject name, subject alternative names, issuer, validity period, and connection status against what you expected. The hostname in the address bar should align with the certificate names, and the certificate should be currently valid and issued by a recognised certificate authority. If the browser shows a warning, mismatch, or unusual issuer details, treat that as a sign to stop and re-check the URL.

For users who want a broader trust model, NIST SP 800-63 Digital Identity Guidelines is useful context for understanding how authenticators and identity assurance are meant to support trust. For a general security control view, NIST SP 800-53 Rev 5 Security and Privacy Controls covers identification and authentication controls, while ISO/IEC 27002:2022 Information Security Controls provides implementation guidance for controls that support trust in the web session and endpoint environment.

What still can go wrong even when the certificate looks valid

A correct certificate only proves that the browser has established a valid encrypted session with the holder of that certificate. It does not prove the site is legitimate in a business sense, that the page has not been compromised, or that the operator is trustworthy. Attackers can obtain valid certificates for malicious domains, clone brand pages, or use lookalike hostnames that appear convincing at a glance.

Failure mechanism: The user relies on the padlock or HTTPS alone and skips the certificate details, so a lookalike domain or fraudulent site can still appear trustworthy enough to collect credentials or payment details.

Impact: The result can be phishing success, credential theft, account takeover, or transaction fraud, especially when the attacker has also copied branding and page design to reduce suspicion. For threat context, the ENISA Threat Landscape is a useful reference point for understanding why trust abuse and impersonation remain persistent attack patterns, and MITRE ATT&CK Enterprise Matrix helps explain how adversaries use credential access and social engineering as part of broader compromise chains.

Standards & Framework Alignment

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

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

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	Website authenticity depends on identity assurance concepts.
Recommendation — Use identity assurance and phishing-resistant verification to confirm the site you reached is the one intended.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Certificate review supports authenticating the site before user action.
	IA-8 — Identification and Authentication (Non-Organizational Users)	Public website verification involves external-facing identity assurance.
Recommendation — Require strong authentication checks before trusting a site session. Verify external identities and presented credentials before accepting the connection as trustworthy.
ISO/IEC 27001:2022	A.5.15 — Access control	Validating the site identity is part of controlling trusted access paths.
Recommendation — Restrict trust to verified access paths and approved destinations.
NIST CSF 2.0	PR.AA-05 — Identity Management, Authentication and Access Control	The question is about confirming identity before interaction.
Recommendation — Apply authentication and identity checks before users trust a destination.
OWASP ASVS	V10 — OAuth and OIDC	The page concerns verifying trust and identity before interacting with a web service.
Recommendation — Validate identity and trust signals before exchanging sensitive data on a web site.

Practitioner Guidance

What to verify: Check the exact hostname, certificate subject, and certificate name entries before entering credentials or making a transaction. If the organisation is sensitive or high-value, compare the URL against a bookmarked or manually typed address rather than trusting search results or email links.

Common mistake: Treating HTTPS as proof of legitimacy. Encrypted transport is necessary, but it is not sufficient to confirm you reached the right website.

Decision rule: If the certificate details do not match the organisation or domain you expected, stop immediately and re-navigate from a trusted source. If the match is correct but the page still feels unusual, verify the URL again before trusting the site’s content or forms.

Practitioner takeaway: The right habit is to verify identity, not just encryption, because the browser can confirm a secure connection while still leaving you on the wrong website.