Credential phishing: an MSP training and prevention guide

TL;DR

Credential phishing is the attack that turns a normal login habit into an access problem. A user thinks they are signing in to Microsoft 365, Google Workspace, a payroll portal, a VPN, a file share, or an invoice system. Instead, they hand the attacker reusable credentials or authentication codes.

For MSPs, the answer is not a one-off warning about suspicious links. The useful workflow combines phishing-resistant MFA where it matters most, clear user rules for login prompts and MFA codes, fast reporting, sign-in log review, and tenant-level evidence that every client has been trained. Credential phishing is an identity risk, a user-behaviour risk, and a managed-service evidence problem at the same time.

What is credential phishing?

Credential phishing is a form of social engineering where an attacker tricks a person into giving away sign-in material. That material can include usernames, passwords, one-time passcodes, recovery codes, MFA approvals, session tokens, or account reset details.

CISA, NSA, FBI, and MS-ISAC describe phishing for login credentials as attackers posing as trusted people or organizations to lure victims into providing credentials. Their joint phishing guidance notes that stolen credentials can give access to enterprise networks, protected resources, email accounts, cloud apps, and business systems.

That is why credential phishing deserves its own playbook. A malicious attachment might create an endpoint incident. A credential phish can create a mailbox incident, an identity incident, a financial fraud path, a data exposure path, and a client-trust problem.

Common credential phishing lures include:

• fake Microsoft 365, Google Workspace, DocuSign, payroll, banking, VPN, or file-share login pages;
• “your password expires today” messages;
• fake MFA reset requests;
• QR-code sign-in pages that move the login to a phone;
• invoice or document links that require “sign in to view”;
• helpdesk or IT messages asking for a code;
• Teams, Slack, SMS, WhatsApp, or voicemail messages that point to a login page;
• attacker-in-the-middle pages that collect both password and one-time code.

For MSP clients, the attacker does not need every user to fail. One mailbox, one admin account, one finance account, or one shared app account can be enough to start the next step.

Why credential phishing matters for MSPs

MSPs live with the consequences after the login has already happened. The client asks whether the account was accessed, whether mail was forwarded, whether invoices were changed, whether customer data moved, whether more users were targeted, whether the insurer should be notified, and whether the business can prove staff were trained.

The risk is visible in public breach reporting. The Verizon 2025 DBIR analyzed 22,052 incidents and 12,195 confirmed breaches. It reports that credential abuse remained the most common vector, while the human element stayed involved in about 60% of breaches. The same report also discusses information-stealer logs and corporate credentials appearing in dumps. Treat those numbers carefully: DBIR data is based on Verizon’s contributor dataset, not every incident in the world. But the direction is hard to ignore. Identity is still a main path in.

Credential phishing creates 6 practical problems for MSPs:

MSP problem	What happens in the client environment	What the MSP needs
Fast account takeover	A user enters a password and code into a fake portal	Reporting path, session revocation, password reset, MFA review
Mailbox abuse	The attacker reads mail, adds forwarding, or sends internal lures	Mailbox audit, forwarding-rule review, user warning, client comms
Client-to-client blast radius	A compromised client mailbox sends trusted lures to customers or suppliers	Tenant-specific containment and notification workflow
Weak MFA confidence	The client thinks any MFA means the account is safe	MFA method review and high-risk account upgrade plan
User embarrassment	The user waits because they fear blame	No-shame reporting language and fast intake
Evidence gaps	The MSP cannot show who was trained or what was covered	Tenant reports, topic coverage, overdue users, exceptions

The training goal is not to make users security analysts. It is to make risky login moments recognizable, reportable, and backed by controls that do not depend on perfect user judgment.

What employees need to recognise

Good credential phishing training focuses less on “does the email look weird?” and more on “is this login request expected, and am I at the real place?” Attackers can copy logos, use clean writing, register lookalike domains, and create realistic portals. Bad grammar is no longer enough as a warning sign.

The FTC’s phishing guidance says phishing messages often tell a story to pressure people into clicking, opening, updating account information, or logging in through a fake site. Microsoft’s phishing guidance points to urgency, external or unfamiliar senders, suspicious domains, unexpected links, and requests through email, text, Teams, social messages, or phone calls.

For credential phishing, turn that advice into client-ready rules:

1. Do not sign in from an unexpected message if you can reach the app another way.
2. Use a bookmark, password manager, or known app launcher for routine sign-ins.
3. Never share MFA codes, recovery codes, or approve a login you did not start.
4. Treat QR-code login prompts as links, not as magic.
5. Report suspicious login prompts before deleting them.
6. Report immediately if credentials were entered, even if nothing looks wrong yet.

The last rule matters most. A fast report can change the whole incident. A slow report gives the attacker time to add inbox rules, create persistence, read sensitive mail, or reuse the account against other people.

What MSPs actually need: a credential phishing operating layer

Awareness is one layer. MSPs also need a repeatable operating layer that works across many clients without rebuilding the process every time.

A practical credential phishing layer includes:

Layer	Purpose	Example MSP action	Evidence to keep
Identity control	Reduce account takeover after credential theft	Enforce MFA, prioritize phishing-resistant MFA for admins and high-risk accounts	MFA method inventory, exception list, rollout notes
User habit	Reduce risky login behaviour	Train users to avoid message-driven logins and never share codes	Topic assignment, completion, quiz or scenario results
Reporting	Shorten time from mistake to containment	One path for suspected phish and “I entered my password” reports	Ticket, timestamp, user details, submitted artifact
Detection	Confirm whether access happened	Review sign-in logs, mailbox rules, sessions, app consent, unusual locations	Investigation checklist, log excerpts, action summary
Client communication	Keep the client clear and calm	Explain what happened, what was checked, and what changed	Client-facing incident note or QBR summary
Continuous improvement	Reduce repeat exposure	Update training, MFA exceptions, conditional access, and risky workflows	Follow-up actions, overdue users, exceptions closed

This is where MSPs can separate themselves from generic training vendors. The client does not only need another definition of phishing. They need an operating path for the moment someone says, “I think I typed my password into the wrong page.”

Step-by-step: how MSPs should reduce credential phishing risk

1. Identify high-risk accounts first

Start with accounts that would hurt most if compromised. For most clients, that means owners, finance, HR, executives, administrators, helpdesk users, shared mailboxes, payroll users, and anyone with access to client records or bank changes.

Do not wait for the perfect identity program. Build a first high-risk list, then improve it. The first pass should answer: who can move money, change access, approve resets, read sensitive data, or influence others?

2. Review the MFA method, not only whether MFA is enabled

MFA is not a checkbox. CISA’s phishing-resistant MFA fact sheet says any MFA is better than none, but phishing-resistant MFA is the gold standard. It calls out FIDO/WebAuthn and PKI-based MFA as phishing-resistant options.

CISA also warns that weaker MFA can be abused through fake login pages, push fatigue, SMS interception, voice-code interception, and SIM swap attacks. That does not mean every SMB can move every user to passkeys or security keys tomorrow. It does mean MSPs should stop reporting “MFA enabled” as if every method carries the same risk.

A better client review separates:

• phishing-resistant options for administrators and high-risk users;
• app-based MFA with number matching or stronger controls;
• basic push approvals;
• SMS or voice codes;
• accounts with no MFA;
• legacy apps that cannot support modern authentication.

That turns a vague security concern into a roadmap.

3. Teach safer sign-in habits

Users need a short rule they can remember when busy: do not log in from surprise messages. If the message says there is a file, invoice, password expiry, payroll notice, or account alert, go to the service through the known path instead.

That known path might be a bookmark, company app portal, password manager, desktop app, browser profile, or official URL. The point is simple. The suspicious message should not control the login journey.

Password managers can help because they usually only fill credentials on the matching domain. Passkeys and FIDO/WebAuthn can help because they use public-key cryptography tied to the legitimate service. Google says passkeys are based on FIDO Alliance and W3C standards and are resistant to phishing, credential stuffing, and other remote attacks. NIST’s phishing-resistance guidance makes the deeper point: phishing resistance should not rely on the user noticing the impostor site.

4. Make MFA-code sharing a hard no

Credential phishing has evolved past password theft. Attackers often ask for the one-time code, trigger a push notification, or walk the user through a fake login in real time.

Training should be blunt:

• Do not read MFA codes to anyone.
• Do not type an MFA code into a page reached from an unexpected link.
• Do not approve a push notification unless you started the login.
• Do not accept pressure from “IT,” “Microsoft,” “the bank,” or “the boss” asking for a code.
• Report any code request as suspicious.

This belongs in onboarding, recurring training, phishing simulations, helpdesk scripts, and client security reminders.

5. Give users one reporting path

Credential phishing response fails when users do not know where to report. Some forward the message to a manager. Some delete it. Some reply to IT. Some wait until they notice something strange.

Create one route. It can be the MSP service desk, a phishing-reporting button, a security mailbox, or a ticket form. The route should handle both cases:

• “I received a suspicious login message.”
• “I entered credentials or approved something.”

The second case needs priority handling. The intake should capture the service involved, username, time, message source, link or QR code, whether MFA was entered, whether an approval was tapped, and whether the user reused that password elsewhere.

6. Build a containment checklist

When a credential phishing report comes in, the MSP should not improvise from scratch.

A basic checklist can include:

1. Disable risky active sessions or revoke refresh tokens where supported.
2. Reset the password and review password reuse risk.
3. Review MFA methods, recent approvals, and registered devices.
4. Check sign-in logs for unusual locations, devices, user agents, impossible travel, or failed attempts.
5. Check mailbox forwarding, rules, delegates, app passwords, OAuth app consent, and sent mail.
6. Review sensitive app access, files touched, invoice systems, payroll systems, and admin changes.
7. Warn affected users or contacts if the account sent further lures.
8. Document what was checked and what changed.

The checklist should be adjusted by client stack. The principle stays the same: fast identity containment, then mailbox/app investigation, then client communication.

7. Turn training into client evidence

Clients increasingly ask for proof. Cyber insurance questionnaires, audits, QBRs, and board questions all push the same direction: show what was done, not what the MSP remembers doing.

Credential phishing evidence should show:

• topic covered;
• users assigned;
• users completed;
• overdue users;
• high-risk role coverage;
• reporting instructions issued;
• exceptions or unsupported MFA methods;
• follow-up actions after tests or incidents.

This evidence does not prove the client is “safe” or “compliant.” It proves scope, coverage, dates, and process. That is the claim an MSP can stand behind.

What good looks like

A good credential phishing program is boring in the places attackers want chaos. Users know not to trust surprise login prompts. Admins have stronger authentication. Helpdesk staff do not ask for codes. Finance and executives know credential theft can become payment fraud. Reports land quickly. The MSP can show coverage by client tenant.

Program element	Weak version	Better version
MFA reporting	“MFA is on”	MFA method by role, with high-risk exceptions visible
Training	Annual phishing module	Recurring credential-phishing scenarios tied to real login workflows
User rule	“Check the link”	Use known sign-in paths; never share codes; report fast
Reporting	Forward suspicious emails if you remember	One reporting path for suspicious messages and entered credentials
Response	Reset password and hope	Session revocation, MFA review, mailbox/app checks, documentation
Evidence	Completion screenshot	Tenant-level coverage, overdue users, topic scope, exception notes

This connects credential phishing to the rest of the MSP human-risk program: social engineering scam training, phishing reporting workflows, security awareness topics, training effectiveness measurement, and auditor-ready client reports.

Mistakes to avoid

Mistake 1: Treating credential phishing as an email-only topic

Credential phishing can arrive through email, SMS, QR codes, Teams, Slack, social messages, calls, search ads, or compromised supplier accounts. Train the login behaviour, not only the inbox warning signs.

Mistake 2: Reporting MFA as a yes/no control

“MFA enabled” is too blunt. SMS codes, voice calls, push approvals, number matching, passkeys, security keys, and certificate-based methods do not carry the same phishing risk. Track method quality, especially for admins and high-risk users.

Mistake 3: Making users feel punished for reporting

A user who typed into a fake login page already feels exposed. If reporting feels like confession, they will wait. Use no-shame language: “Report fast so we can contain it.”

Mistake 4: Forgetting mailbox persistence

Changing the password is not always enough. Check forwarding rules, delegates, suspicious sent mail, OAuth app consent, app passwords, inbox rules, and external access where relevant.

Mistake 5: Leaving no client-facing record

If the client asks what happened or what was trained, the MSP needs more than a ticket note. Keep an evidence trail that can be used in a QBR, insurer conversation, audit support pack, or post-incident review.

Framework mapping for MSP client programs

Credential phishing training and identity controls can support several client conversations. Use careful language. Training is evidence for awareness and response process. It does not prove the whole framework or guarantee breach prevention.

Framework or requirement area	How credential phishing work can support it	Evidence to keep
NIST CSF awareness and identity conversations	Users learn credential-risk behaviours and expected reporting paths	Training topic, completion, role groups, reporting instructions
CISA Cybersecurity Performance Goals	CISA phishing guidance maps user training and anti-phishing measures into baseline cyber hygiene	Training records, MFA review, reporting process, email/domain-control notes
Cyber insurance questionnaires	Client can show phishing training, MFA posture, and response process	Completion report, MFA exceptions, incident-response checklist
ISO 27001 awareness and access-control evidence	Awareness training and access-control hygiene support audit conversations	Scope, dates, attendees, overdue users, exceptions, access-review notes
QBR and executive reporting	MSP can show credential-phishing readiness across tenants	Coverage trend, risky roles, overdue users, incidents, next actions

The strongest client message is simple: here is who was trained, what they were trained on, what sign-in controls are in place, what exceptions remain, and what happens if someone reports a mistake.

How a flat-rate MSP SAT platform helps

Credential phishing is a bad fit for per-seat rationing. If only “important” users get trained, attackers will look for the untrained person with access to mail, files, payroll, invoices, or support workflows.

DefendWise gives MSPs a flat-rate, white-label, multi-tenant way to deliver security awareness across every client user and keep reporting clean by tenant. If you want to test AI-native awareness training without turning every new phishing topic into another admin job, start with the 7-day free trial.

Frequently asked questions

What is credential phishing?

Credential phishing is a social engineering attack that tricks a person into giving away sign-in material. That might be a password, one-time code, recovery code, MFA approval, or other authentication detail. The attacker uses it to access email, cloud apps, VPNs, file stores, finance tools, or other business systems.

How is credential phishing different from phishing?

Phishing is the broad category. It can aim to steal money, deliver malware, collect personal data, trick someone into sending a payment, or compromise an account. Credential phishing is the form focused on stealing login material or authentication outputs.

Does MFA stop credential phishing?

MFA reduces risk, but not every MFA method resists phishing. CISA says phishing-resistant MFA is the strongest option and identifies FIDO/WebAuthn and PKI-based approaches as phishing-resistant. SMS, voice codes, and basic push approvals can still be abused in some attack paths.

What is phishing-resistant MFA?

Phishing-resistant MFA is authentication designed so a user cannot simply hand a valid secret or code to a fake site. NIST describes phishing resistance as preventing disclosure of authentication secrets or valid authenticator outputs to an impostor relying party without depending on the user’s vigilance. Common commercial examples include FIDO/WebAuthn security keys and passkeys where supported.

What should employees do after entering credentials on a phishing page?

They should report it immediately through the approved security path. The MSP or IT team can then reset credentials, revoke sessions, review MFA methods, check sign-in logs, inspect mailbox rules and app access, and decide whether further containment or notification is needed.

Are QR-code phishing attacks part of credential phishing?

They can be. QR codes often move the user from a computer screen to a phone, where link inspection can be harder. If the QR code leads to a fake login page and collects credentials or MFA codes, it is credential phishing.

Should MSPs train every user or only high-risk users?

Every user needs baseline credential-phishing training because any mailbox or app account can become a launch point. High-risk users also need deeper examples: admins, finance, HR, executives, helpdesk, payroll, and anyone who can approve access, money, or sensitive data changes.

How can DefendWise help MSPs train clients on credential phishing?

DefendWise helps MSPs deliver flat-rate, white-label, multi-tenant security awareness training. That makes it easier to cover every user, keep phishing topics current, and produce tenant-ready reporting for client conversations.

Sources

• CISA, NSA, FBI, MS-ISAC: Phishing Guidance: Stopping the Attack Cycle at Phase One
• CISA: Implementing Phishing-Resistant MFA
• CISA: Multifactor Authentication
• NIST: Phishing resistance: protecting the keys to your kingdom
• NIST: Multi-factor authentication
• FTC: How to recognize and avoid phishing scams
• Microsoft: Protect yourself from phishing
• Google Safety Center: Authentication tools for secure sign-in
• Verizon: 2025 Data Breach Investigations Report
• FBI: Business email compromise
• NCSC: Phishing: spot and report scam emails, texts, websites and calls
• CISA: Report a cyber issue