Dipak D. Kuthe · Originally published July 12, 2026
If a message asks for a password, verification code, payment, or bank-detail change, stop and verify the request through a channel you already trust. Open the service from a saved bookmark or call the contact in your existing records. Report suspicious requests promptly, especially if someone already entered information, approved a sign-in, or sent money.
Recognize the request across channels
Phishing uses impersonation to persuade someone to disclose information or take an unsafe action. Spear phishing targets a particular person or team. Business email compromise (BEC) typically abuses an impersonated or compromised business identity to divert payments or obtain sensitive information. It can happen in a genuine email thread and requires neither a malicious link nor an attachment.
| Channel | What to watch for | How to verify safely |
|---|---|---|
| Unexpected invoice changes, unfamiliar reply addresses, or requests to open a document and sign in | Open the approved finance or document portal directly. Call a contact from your vendor records if payment instructions changed. | |
| SMS or chat | Unexpected delivery, payroll, or account warnings that ask you to follow a link | Open the official app or use a saved address. Report the message through your internal channel. |
| QR code | An unexpected code asking you to sign in or pay | Skip the code and open the known service yourself. Ask the issuing team through a trusted channel whether it sent the request. |
| Voice | A caller posing as IT, a bank, or a supplier asks for codes, remote access, or payment | End the call and dial the number in your directory or on the bank’s official materials. Caller ID is insufficient verification. |
Look for pressure, a request to keep the transaction secret, an unexpected attachment, or a change to an established process. Familiar branding, polished language, and a real sender address cannot establish that a request is authorized. FBI business email compromise guidance · FTC QR-code guidance
Make verification part of finance and IT workflows
Require independent confirmation before updating vendor bank details or releasing an unusual payment. Use a phone number already on file, record who confirmed the change, and have a second approver check the evidence before releasing funds. If the vendor cannot be reached, hold the payment. Use the same principle for requests to reset credentials, enroll a new authentication method, or grant remote access.
Give staff a mail reporting button and a backup phone or ticket channel they can reach if they lose account access. Ask for the time, channel, and action taken, including whether they opened an attachment, entered a password, approved MFA, or sent money. Preserve the original through the approved reporting workflow and avoid forwarding suspicious material to colleagues. Train teams on their own workflows and measure whether reports reach the responder promptly. CISA phishing guidance
Layer phishing-resistant sign-in and email controls
Prioritize phishing-resistant authentication for administrators, finance staff, and email users. FIDO2 security keys and WebAuthn passkeys bind authentication to the legitimate service. SMS codes, authenticator codes, and ordinary push approvals offer protection over passwords alone but are not phishing-resistant. Pilot enrollment and recovery and review fallback methods before enforcement. A strong sign-in method still leaves room for fraudulent payments, unsafe app consent, or compromise of an already authenticated device. CISA phishing-resistant MFA guidance
SPF identifies authorized sending infrastructure for an envelope domain. DKIM provides a verifiable signature over selected parts of a message. DMARC checks whether a passing SPF or DKIM identity aligns with the visible From domain and publishes policy and reporting preferences. Inventory every legitimate sender, verify alignment, and review reports before tightening enforcement. These controls help defend your domain against spoofing. A lookalike domain or a genuine compromised mailbox can still pass authentication for its own domain. Pair authentication with message filtering, impersonation alerts, endpoint protection, and timely patching. Microsoft email authentication guidance
Respond according to what happened
| Employee action | First response |
|---|---|
| Received a suspicious request or opened a link without knowingly entering data | Report promptly with the time and what happened. IT checks the message, destination, and available endpoint or browser evidence before deciding whether containment is needed. |
| Entered credentials, approved an unexpected sign-in, or granted app access | Contact IT immediately through the backup channel. IT assesses account containment, resets exposed credentials through the trusted service, revokes sessions as appropriate, and checks authentication methods, app grants, and mailbox changes. |
| Ran a file or installed a tool | Contact IT immediately. Follow the incident team’s directions for device isolation and preserve evidence. |
| Sent a payment or disclosed bank details | Alert finance and IT immediately. If money moved, call the bank using its known fraud number and request assistance with a recall. Preserve payment records and messages. |
Identity-provider revocation and application session termination can behave differently. Verify containment in the affected applications and monitor sign-in and mail activity. A password reset alone may leave forwarding rules, unexpected app grants, or some sessions in place. Microsoft compromised mailbox response · Microsoft Entra session revocation
Fictional incident: a supplier payment request follows a suspicious sign-in
Illustrative incident. CoreSecTech did not investigate or test this scenario.
Detection. A finance employee reports entering their work password and approving an unexpected MFA prompt. A coworker separately reports a bank-detail change sent from that employee’s mailbox. Finance puts the payment on hold and calls the supplier on the number already on file. IT records both reports and preserves the messages and relevant sign-in events.
Containment. IT temporarily blocks the affected account, resets its credentials, and revokes sessions using the identity provider’s response process. It checks for unfamiliar authentication methods, mailbox forwarding, inbox rules, and app grants. It reviews message traces to identify recipients who need a warning through a verified channel. If the payment had already gone out, finance would contact the bank immediately.
Recovery. IT verifies that unauthorized rules and grants are gone, checks for continued suspicious activity, and restores access after confirming the employee’s identity and approved authentication methods. Finance checks the supplier record and releases payment only through its normal approval process. Record which logs were available and any gaps that remain.
Lessons learned. Test whether a locked-out employee can reach IT without email. Review time from first report to payment hold, verify that a second approver can see the callback evidence, and prioritize phishing-resistant sign-in for the finance team. Office network security verification guide