Anti-Phishing Controls for Microsoft 365: A CISA and NIST AT-Family Operating Plan

The strongest Microsoft 365 anti-phishing program is not one setting. It combines mail-flow controls, phishing-resistant authentication, a fast report-and-investigate workflow, and role-specific training. For a Modesto school district, that means protecting the finance inbox, substitute-teacher accounts, and student-data workflows together—not treating awareness training as a checkbox.

The decision lands in a Modesto district finance inbox

At 7:42 a.m. on the first business day after a school holiday, a Modesto Unified School District accounting specialist opens Outlook to approve a vendor payment before the morning bell schedule gets busy. The message appears to come from the superintendent. It asks her to confirm a new bank account for an instructional-services vendor and includes a link to a Microsoft 365 sign-in page.

The district’s email gateway has not obviously failed. The message passed through. The user has multifactor authentication, but the attacker is relying on a convincing fake login page and an approval prompt—not merely a stolen password. If the user submits credentials, the attacker may gain access to mail conversations, create forwarding rules, impersonate administrators, or change the payment instructions before anyone notices.

That is the operating problem this article addresses: how to align Microsoft 365 anti-phishing controls with CISA guidance and the NIST SP 800-53 Awareness and Training family while preserving a workflow that a real district can operate.

We would approach this through our K-12 IT and managed cybersecurity teams, with named owners for configuration, monitoring, training, and incident escalation.

What does CISA expect a Microsoft 365 anti-phishing plan to cover?

CISA’s guidance points to several layers rather than a single product feature. Phishing can use harmful links, attachments, or requests for information, so the defense must address the message, the identity, the user decision, and the investigation that follows.¹

For Microsoft 365, that translates into five control layers:

• Authenticate the sender and domain: Use SPF, DKIM, and DMARC deliberately, monitor DMARC reports, and investigate unauthorized senders.
• Inspect the message and destination: Configure anti-phishing, spoof intelligence, impersonation protection, Safe Links, and attachment protections appropriate to the tenant’s licensing.
• Protect the account: Require MFA, prioritize phishing-resistant methods for administrators and high-value users, and remove legacy authentication paths where business requirements permit.
• Make reporting easy: Give users a visible Outlook reporting action and route reports to a monitored mailbox, Microsoft, or both.
• Train for the actual decision: Teach employees how to verify a payment change, password request, shared document, or urgent executive message—and measure whether they report it.

CISA specifically identifies phishing-resistant MFA as the strongest form of MFA and recommends that organizations make migration to it a high priority.¹ That does not mean a district can replace email controls with security keys overnight. It means the identity roadmap should start with Global Administrators, finance staff, executive assistants, IT administrators, and anyone who can approve payments or access sensitive student records.

Which Microsoft 365 controls should we configure first?

Start by separating baseline protection from advanced protection. Microsoft documents basic anti-phishing features for cloud mailboxes, including spoof intelligence, first-contact safety tips, and unauthenticated-sender indicators. Defender for Office 365 adds user, domain, and sender impersonation protection, adjustable phishing thresholds, and additional reporting.²

1. Establish the domain-authentication baseline

Review every domain that sends mail on the district’s behalf, including marketing platforms, payroll providers, transportation vendors, learning platforms, and emergency-notification services. A domain that is not used for sending should not be treated like one that is.

CISA recommends adopting at least a monitoring-oriented DMARC policy and maintaining visibility into DMARC findings and reports.³ The operational goal is not to publish a record and forget it. It is to identify legitimate senders, correct alignment failures, and then make unauthorized use progressively harder without breaking a critical vendor workflow.

Document:

• Which domains send email.
• Which vendors send using the district’s domain.
• Who owns each SPF, DKIM, and DMARC change.
• Where DMARC reports are reviewed.
• What evidence is retained when a sender is blocked or allowed.

2. Protect people who are likely to be impersonated

In Microsoft Defender, create a protected-user list that reflects the district’s payment and operational reality⁴. It may include the superintendent, chief business official, accounts-payable staff, payroll managers, principals, transportation leadership, and IT administrators.

Create a protected-domain list for the district’s primary domains and commonly abused lookalike patterns. Configure impersonation safety tips and mailbox intelligence, but do not automatically add every familiar address to a trusted-sender list. A broad allowlist can turn a carefully designed control into a bypass.

Microsoft’s documentation describes mailbox intelligence as a way to use contact history to distinguish legitimate and impersonated senders. The practical implication is that configuration must be reviewed against real communication patterns: vendor changes, board communications, payroll cycles, and seasonal staff onboarding.²

3. Treat links as a separate control problem

A message can look harmless while its destination is malicious. Configure Safe Links policies for email and collaboration locations covered by the tenant’s Microsoft licensing. Decide whether links are checked at time of click, whether users receive a warning, and how exceptions are handled for security testing or trusted operational systems.

Do not use allowlists as a substitute for validation. If a payroll provider’s URL is routinely allowed, confirm ownership and business need, document the exception, and review it. A link that was legitimate last year may now redirect through a compromised account or an abandoned domain.

4. Remove authentication paths that phishing can bypass

CISA recommends MFA, unified audit logging, alerting, least privilege, and disabling legacy email protocols when they are not required.⁵ For a Microsoft 365 tenant, that means reviewing POP, IMAP, SMTP AUTH, old mail clients, service accounts, and unmanaged devices rather than assuming “MFA is enabled” closes the issue.

Use a staged decision:

Control decision	Practical action	Owner	Evidence to retain
Administrator access	Require phishing-resistant MFA where supported; reduce standing Global Administrator access	Security lead and identity administrator	Conditional Access policy, group membership, exception record
Finance and executive accounts	Apply stronger authentication and sign-in risk policies; require callback verification for payment changes	CFO or business office plus IT	Approved workflow, policy acknowledgment, test result
Legacy protocols	Identify POP, IMAP, SMTP AUTH, and old clients; disable or narrowly scope exceptions	Microsoft 365 administrator	Sign-in report, exception expiration date
Impersonation	Protect high-value users and domains; enable mailbox intelligence and safety tips	Messaging administrator	Policy export, test messages, review notes
User reporting	Configure Outlook Report phishing and route submissions to a monitored destination	Security operations	Sample report, mailbox routing, response record
Investigation	Enable unified audit logging and alerting; connect to a SIEM if appropriate	Security operations	Audit search, alert rule, case number

The table is intentionally operational. A control is not complete when a toggle is green; it is complete when somebody owns it, exceptions expire, and the organization can demonstrate what happened during a test or incident.

How should the NIST SP 800-53 AT family change security awareness training?

The Awareness and Training family is useful because it turns “send a phishing tip” into a managed control. NIST’s SP 800-53 material describes practical exercises that simulate social-engineering attempts, malicious attachments, and spear-phishing links.⁶ NIST also describes role-based training as comprehensive training that addresses management, operational, and technical roles.

For a Modesto district, that suggests at least three training tracks.

General awareness for every employee

Keep the content short and tied to decisions people actually make:

• Stop when a message creates urgency or secrecy.
• Inspect the sender and destination without trusting the display name.
• Use a known phone number or established workflow to verify payment changes.
• Report suspicious messages before forwarding them to colleagues.
• Never approve an MFA prompt that the user did not initiate.

This is the AT-2-style foundation: employees need repeatable knowledge and a way to demonstrate that they retained it. Annual training may be a minimum in some programs, but a district should also use targeted refreshers after a real campaign, a near miss, or a major Microsoft 365 configuration change.

Role-based training for high-impact workflows

The accounting specialist in the opening scenario needs different practice from a classroom teacher. Train finance staff on bank-change requests, invoice fraud, callback verification, and separation of duties. Train principals on urgent superintendent requests. Train IT staff on consent phishing, OAuth applications, suspicious inbox rules, and account recovery.

This is where AT-3 alignment becomes concrete: training follows the role’s access and decisions, not the employee’s department name alone.

Practical exercises with measurement

If the district uses Microsoft Defender for Office 365 Plan 2 or Microsoft 365 E5, Attack Simulation Training can measure and manage social-engineering risk through controlled phishing simulations⁷. Use it carefully:

1. Define the behavior to test—reporting, credential submission, or verification of a payment change.
2. Exclude emergency operations and avoid campaigns during payroll, testing, enrollment, or crisis response.
3. Send a test message to a small pilot group first.
4. Measure reports, clicks, credential submissions, and time to report.
5. Assign brief corrective training rather than publicly shaming users.
6. Compare results by role and campaign, not as a simplistic employee ranking.

The evidence should include the campaign objective, audience, results, assigned training, and follow-up review. That creates a defensible record for the AT family and gives leadership a way to decide whether the control is improving.

What happens when an employee reports a suspicious message?

A report button without an owner is theater. Microsoft documents that users can report phishing and suspicious email from Outlook, and administrators can route those submissions to a specified reporting mailbox, Microsoft, or both.

We recommend a defined workflow:

• User: Selects Report phishing and does not reply, click, or forward the message.
• Triage owner: Reviews the message, sender, URLs, authentication results, and affected recipients.
• Containment owner: Searches for matching messages and removes or quarantines them where appropriate.
• Identity owner: Checks sign-ins, MFA prompts, consent grants, inbox rules, forwarding, and token activity for users who interacted with the message.
• Business owner: Verifies any payment, payroll, vendor, or schedule change through an established channel.
• Incident lead: Escalates when credentials were entered, a mailbox was accessed, or sensitive data may have been exposed.
• Training owner: Converts the incident into a targeted lesson or simulation without exposing unnecessary personal information.

For public safety, healthcare, finance, and local-government environments, the workflow also needs evidence handling and clear escalation. A suspicious message affecting a CJIS-regulated dispatch environment or a clinic’s EHR support account should not sit in a general help-desk queue with no security owner.

How do we prove the controls are working?

Measure the control system, not just the number of users who clicked a simulation.

Useful monthly measures include:

• Percentage of privileged and high-value accounts using phishing-resistant MFA.
• Number of legacy-authentication exceptions and their expiration dates.
• DMARC reports reviewed and unauthorized senders investigated.
• Time from user report to triage.
• Time from confirmed phishing to search-and-containment action.
• Number of suspicious messages reported before anyone clicked.
• Percentage of role-based training completed and passed.
• Repeat behavior after corrective training.
• Audit-log searches completed for simulated or real events.

CISA’s Microsoft 365 recommendations emphasize unified audit logging because it provides a record of activity across services and supports investigation of potentially malicious actions. That makes logging part of the anti-phishing control, not merely a post-incident convenience.

What should a Datapath engagement deliver?

A useful engagement should leave the organization with more than a security-policy PDF. We would help establish:

• A Microsoft 365 anti-phishing configuration baseline.
• A protected-user and protected-domain inventory.
• An SPF, DKIM, and DMARC ownership map.
• A phishing-reporting and escalation runbook.
• A role-based training matrix for executives, finance, IT, educators, dispatch, and clinical or public-sector staff where applicable.
• A practical-exercise schedule and measurement plan.
• A documented exception register for legacy protocols, trusted senders, and business-critical links.
• A monthly security review with a named Datapath team—not an anonymous ticket queue.

Depending on the gap, that may include security awareness training, vCISO services, a managed IT services operating model, or an incident response retainer.

The point is not to promise that Microsoft 365 can make phishing disappear. The point is to make the attacker’s path narrower, make the user’s safe action obvious, and make the organization’s response fast enough to limit damage. If your Modesto, Fresno/Central Valley, Modesto, or California organization wants to turn those settings into an accountable operating process, talk with Datapath.

---

Footnotes

1. Fetched web page ↩ ↩²

2. Anti-phishing policies in Microsoft 365 - Microsoft Defender for Office 365 | Microsoft Learn ↩ ↩²

3. Fetched web page ↩

4. Attack simulation training deployment considerations and FAQ - Microsoft Defender for Office 365 | Microsoft Learn ↩

5. Microsoft Office 365 Security Recommendations | CISA ↩

6. Fetched web page ↩

7. Report phishing and suspicious emails in Outlook for admins - Microsoft Defender for Office 365 | Microsoft Learn ↩