The login page is real. The request can still be a trap

The most unsettling page in a phishing workflow may not be counterfeit at all. It may open at a genuine identity-provider address and authenticate the user exactly as designed. The deception may have happened earlier, when somebody persuaded that user to begin the wrong process. A genuine interface then becomes part of a malicious workflow.

This is the weakness in the familiar instruction to spot the fake. It treats authenticity as a visual judgement, inferred from grammar, design, branding, links or the appearance of a sign-in screen. Those clues still have value, but they cannot answer the decisive question: is this request legitimate? Modern phishing defence must move from inspecting appearances to verifying processes.

Trust is not a single test

What we casually call trust is really a series of separate decisions. Does the message look plausible? Where did it technically originate? Is the interface genuine? Did the correct person authenticate? What device, session or application did that person authorise? Is the resulting payment, account change or access request legitimate?

Passing one test does not settle the next. A familiar design does not prove origin. A real domain does not prove benevolent intent. Successful authentication proves something about the user, not necessarily the action being approved. Even a valid permission can be dangerous when it is granted to the wrong application.

This distinction is not theoretical. Microsoft reported in February 2025 that Storm-2372 used legitimate device-code authentication flows. Victims entered attacker-supplied codes on genuine sign-in pages, completing an authentic process that granted access and refresh tokens. In the environments Microsoft investigated, the company observed account access and email exfiltration.

That mechanism should not be collapsed into every other kind of phishing. Microsoft separately reported in March 2026 that attackers had abused legitimate OAuth redirection behaviour and identity-provider URLs to direct people towards attacker-controlled infrastructure. OAuth consent phishing presents another problem again: Microsoft Entra guidance explains that a user can authenticate through a legitimate identity provider and still delegate permissions to a malicious application.

The common lesson is not that trusted services are fake or compromised. It is that legitimate infrastructure can perform its intended function inside a workflow whose overall purpose is malicious. Security education that stops at checking the page, domain or padlock stops one layer too soon.

Polish is weak evidence

Poor spelling and crude design have long served as convenient phishing warnings. They remain useful when present, but they are no longer dependable as the foundation of detection. The UK National Cyber Security Centre assessed in 2024 that generative AI could remove spelling and grammar clues and make legitimacy harder to judge. Its 2025 update characterised AI mainly as an enhancement to existing tactics, including social engineering, rather than the creator of wholly new threat vectors.

That is the right proportion. AI can improve presentation and scale, but it is not necessary to explain every polished lure. The deeper problem is structural: attackers can direct people into ordinary authentication, sharing and consent functions. Professional language makes the approach easier to accept, while the trusted interface reassures the victim after the consequential decision is already under way.

Traditional warning signs should not disappear from training. The NCSC still advises people to examine authority, urgency and emotional pressure, alongside suspicious or unexpected requests. Australian Cyber Security Centre guidance also warns that phishing may ask people to link devices through QR codes or disclose registration PINs and verification codes. These behavioural clues are useful because they focus attention on what the sender wants the recipient to do.

But even these clues are not universal. A calm, well-written request may still be dangerous. The durable question is therefore not whether a message feels suspicious. It is whether the requested action can be confirmed independently of the message and the path it provides.

Authentication is not authorisation

The standard advice to enable multi-factor authentication remains important, but it is incomplete. MFA is not one uniform defence, and successful MFA does not prove that the right thing was approved. In a deceptive device-code flow, a victim may complete legitimate authentication while connecting an attacker-controlled session. In consent phishing, the user may authenticate correctly while granting inappropriate delegated permissions.

Passkeys and other phishing-resistant authentication methods are substantial improvements, not failed promises. Australia’s cyber.gov.au says passkeys can prevent password theft through fake websites and recommends another phishing-resistant method where passkeys are unavailable. The Australian Information Security Manual likewise recommends phishing-resistant MFA against real-time phishing.

Those controls address an important problem: the theft or replay of credentials through a fake site. They do not independently decide whether an application deserves access, whether a device should be linked or whether a business request is legitimate. The Information Security Manual notes that illicit consent grants can leave OAuth tokens operating independently of user credentials and surviving password resets.

If passkeys become widespread while organisations continue to permit broad application consent or unrestricted device-code authentication, some attackers could concentrate more heavily on persuading users to approve applications, devices or business actions. That is a possibility, not a measured forecast. The available evidence does not establish how frequently such a shift would occur, and implementations vary. It does show why identity security cannot end with stronger login technology.

Move the burden away from intuition

Users should not be expected to reverse-engineer intent from a polished screen under time pressure. Organisations should design high-risk actions so that an inbound message cannot complete the whole process. The US Federal Trade Commission advises people who think a message may be legitimate to contact the organisation through a phone number, email address or website already known to be real. Australian guidance similarly recommends using official channels when a message or call is doubtful.

In practice, that means independently opening the relevant account rather than following a supplied link or QR code. Unexpected permission, device-linking, payment, recovery and support requests should require confirmation through a separate trusted path. Organisations must also let employees pause an urgent request without penalty. A verification procedure is of little use if workplace incentives encourage people to bypass it.

Administrators have a larger role than another round of awareness slides. Microsoft classifies device-code flow as a high-risk authentication method and recommends blocking it where possible, with documented exceptions. That qualification matters. The flow has legitimate uses for input-constrained systems, so a blanket ban may disrupt genuine operations. The sound approach is to permit it where necessary, record those use cases and restrict it elsewhere.

These controls create friction. Independent checks take time, restrictive policies need maintenance and recovery paths must work when legitimate users are locked out. Yet this is more defensible friction than asking every employee to detect malicious intent from visual quality. The organisation controls the authentication environment and business process, so it should carry more of the verification burden.

The old model asked whether a message looked real. The better model asks whether each step is appropriate: the message, its origin, the interface, the authentication, the permission and the final action. Security comes from refusing to let success at one layer confer automatic trust on all the others.

A real login page can prove that the login page is real. It cannot prove that the person who sent you there had a legitimate purpose. Trust the independently verified process, not the polish of the path that led to it.

Separating authentication from authorisation raises wider questions about how trust moves across connected systems. Readers who want the broader foundations can explore The Hack Academy’s online cybersecurity training programme, with self-paced learning in cybersecurity fundamentals, networking and internet vulnerabilities, supported by practical exercises alongside theory.