Security questionnaires used to feel like paperwork after the real security work was done. That is no longer a safe assumption. In late September 2026, two signals landed in the same week: Microsoft described an AI-assisted phishing service that compromised more than 12,000 inboxes across more than 10,000 organizations, and CISA continued pushing vulnerability management away from generic severity lists toward evidence of active exploitation. For founders and operators, the message is blunt: your next customer review may care less about whether you have a policy and more about whether your logs prove the control is alive.

On September 22, 2026, Microsoft published its analysis of EvilTokens, a phishing-as-a-service platform that abused legitimate device-code authentication flows. The attack did not need to steal a password in the traditional sense. A user could be tricked into entering a code on a legitimate Microsoft sign-in page, unknowingly authorizing the attacker’s session. Microsoft said the service used AI to tailor phishing lures, analyze compromised inboxes, identify high-value targets, and support business email compromise activity. That matters operationally because the attacker’s first win was not malware on a laptop. It was a valid-looking identity session attached to a real mailbox.

Mailbox Compromise Is Now a Control Test

Small and midsize companies often treat email security as a bundle of settings: SPF, DKIM, DMARC, MFA, spam filtering, and user training. Those still matter, but the EvilTokens case shows why buyers are starting to ask harder questions. If an attacker gets a token, can they create forwarding rules? Can they register a device? Can they use Microsoft Graph or Google Workspace APIs to map the company? Can they search for invoices, wire instructions, payroll approvals, legal threads, or customer security questionnaires?

The practical answer should be visible in your environment. You need to know whether device-code authentication is blocked or tightly scoped. You need conditional access rules that make security-info registration, risky sign-ins, and unmanaged-device access harder to abuse. You need alerts for suspicious inbox rules, OAuth grants, impossible travel, abnormal mailbox downloads, and privilege changes. Just as important, you need a response record that shows what happened when those alerts fired: who triaged them, what evidence was reviewed, what access was revoked, and what follow-up controls changed.

That evidence is exactly what separates a confident security review from a scramble. A questionnaire answer that says “MFA is enabled” is thin. An answer that says “phishing-resistant MFA is required for administrators, device-code flow is blocked except for named resource accounts, suspicious inbox rules generate alerts, and our last quarterly test on September 12, 2026 verified response ownership” is much harder to dismiss.

CISA Is Moving the Patch Conversation Toward Risk

The same shift is happening in vulnerability management. On September 25, 2026, CISA added CVE-2026-65660 affecting Microsoft SharePoint and CVE-2026-67279 affecting MikroTik RouterOS to the Known Exploited Vulnerabilities catalog based on evidence of active exploitation. CISA’s language is consistent: these vulnerabilities are frequent attack vectors and organizations should prioritize remediation based on risk, not just theoretical severity.

On September 28, 2026, CISA also sunset its Weekly Vulnerability Bulletin, pointing users toward sources such as the KEV catalog, CISA alerts and advisories, CVE.org, and vendor security alerts. For a small business, this is not just a change in reading habits. It changes the operating model. A monthly spreadsheet sorted by CVSS score is no longer enough when a lower-scored issue on an internet-facing system is being actively exploited and a higher-scored internal issue is not reachable.

The lightweight version of a mature workflow is simple: maintain an asset list, know which systems are internet-facing, subscribe to vendor and KEV signals, tag vulnerabilities that map to exposed services, assign owners, define remediation deadlines, and preserve proof. Proof can be a ticket, scanner output before and after remediation, a vendor advisory, a firewall rule review, a compensating-control note, and an exception with an expiration date. The point is not to create bureaucracy. The point is to make the next exploited-vulnerability alert actionable in hours instead of days.

Questionnaires Are Asking for Receipts

SOC 2, PCI, HIPAA, and FedRAMP-aligned reviews each use different language, but they increasingly converge on the same operational questions. Who can access production and sensitive data? How is email protected from spoofing and account takeover? How are vulnerabilities prioritized? How quickly are exploited issues fixed? How do you detect suspicious activity? What evidence proves this is happening repeatedly?

FedRAMP’s 2026 movement toward machine-readable authorization packages reinforces the same direction. The future of security evidence is less “upload a static policy once a year” and more “show structured, current, traceable control evidence.” Even if your company is nowhere near a federal authorization, large enterprise buyers often borrow the posture. They want faster reviews, fewer hand-wavy answers, and evidence that does not require your CTO to disappear for three days every time procurement asks a question.

For smaller teams, the trap is trying to buy a platform before the workflow exists. Start with the controls most likely to affect customer trust and real-world compromise: identity, email, endpoint coverage, backups, vulnerability remediation, vendor access, and incident response. Then make the evidence boring and repeatable. A boring evidence folder with dated exports, ticket links, screenshots, policy versions, and decision notes beats a polished policy that nobody can prove.

What to Do This Week

First, review your Microsoft 365 or Google Workspace identity settings. Block or restrict device-code authentication where possible. Require phishing-resistant MFA for administrators and high-risk roles. Check whether users can create external forwarding rules, consent to risky apps, or register new authentication methods from unmanaged devices. Pull a sample of sign-in logs and mailbox-rule events from September 2026 and confirm someone can explain them.

Second, update your vulnerability workflow around active exploitation. Add CISA KEV and vendor advisories to the intake process. Tag internet-facing assets. Create a short rule for emergency patching: if it is exploited in the wild and present in your environment, it jumps the queue. Document the owner, date found, date fixed, and validation method.

Third, turn this into customer-ready language. Do not wait for the next questionnaire to invent your answer. Write the answer now, attach evidence, and identify gaps honestly. A practical response packet for email and identity hardening should include current MFA requirements, conditional access screenshots or exports, DMARC status, alert coverage, sample incident tickets, and recent access-review notes. A vulnerability packet should show scan cadence, prioritization rules, KEV monitoring, remediation SLAs, and examples of closed tickets.

The operational lesson from September 2026 is not that every company needs a bigger security department. It is that security work has to leave a trail. If your inbox, identity provider, and patch queue can tell a clear story, customer reviews get easier and attacks get harder. That is the kind of readiness worth building before the next urgent questionnaire arrives.

Why this matters

GGEZ can help founders and operators harden Microsoft 365/Google Workspace identity controls, build phishing-resistant workflows, tune alerting, and turn vulnerability and mailbox response activity into audit-ready evidence for SOC 2, PCI, HIPAA, FedRAMP-aligned questionnaires, and customer security reviews.

Sources

Need help applying this?

If your team needs practical security help instead of generic checklists, GGEZ can help you harden the basics and organize the work. See the related service area.