Deceptive request or verifier
Phishing uses a deceptive message, site, call, or interaction to cause disclosure or action. It can steal a password or one-time code, relay authentication to the real verifier, install malware, capture a session, obtain payment, change recovery, or induce an authorized transaction.
Spear phishing targets a person or role. Smishing uses text messages. Vishing uses voice. The delivery channel does not define the final security failure.
Phishing resistance
A phishing-resistant authentication protocol prevents an impostor verifier from obtaining reusable secrets or valid authenticator output without relying on the claimant to notice the deception. Origin-bound public-key authentication such as correctly deployed WebAuthn can provide this property. Passwords, one-time codes, and push approval without transaction binding remain phishable or relayable.
Phishing resistance protects the authentication ceremony. It does not stop malware or a malicious action inside the correct application origin.
Layered controls
Use authenticated email and messaging where applicable, link and attachment controls, domain monitoring, browser and endpoint protection, phishing-resistant authentication, clear transaction context, limited sessions, application reauthorization for high-impact actions, and simple reporting. Detect unusual enrollment, recovery, session, forwarding, payment, and federation changes.
Train people on current tasks and give them a fast safe alternative. Measure message difficulty and context before interpreting simulation results.
Failure and residual risk
A user can authenticate safely to the correct origin and then approve an attacker-directed action. Session theft can bypass a strong initial ceremony. Support can replace a resistant authenticator through a phishable process. A clicked simulation does not prove compromise, and a low click rate does not prove protocol resistance.
Blocking obvious messages can shift attackers to trusted accounts, search ads, collaboration tools, QR codes, phone calls, and vendor workflows.
Pomerium boundary
Pomerium delegates user authentication to the configured identity provider and consumes the result. The provider owns the authenticator ceremony and recovery. Pomerium policy can restrict covered routes and sessions, but it cannot make a provider's password or one-time-code flow phishing resistant or prevent unsafe actions inside an authorized upstream.
Evaluation checklist
- Is the attacker stealing a secret, relaying a ceremony, installing code, capturing a session, or inducing a valid action?
- Does the authenticator bind output to the real verifier or origin without user vigilance?
- Can recovery, enrollment, support, or session reuse bypass the resistant ceremony?
- Do reporting and containment revoke credentials, authenticators, sessions, forwarding, and application changes?
- Are training results adjusted for message difficulty, role, opportunity, and the actual harm prevented?
