Public-safe engineering work.

Most M365 tenants ship with permissive defaults. Security incidents in M365 environments are frequently identity-based: compromised accounts, phishing that bypasses weak MFA, admin roles that are too broad, or guest access that has no lifecycle.

A compromised credential without MFA resistance leads to full mailbox access and lateral movement. Legacy authentication bypasses Conditional Access entirely. Admin roles assigned without PIM mean persistent elevated access with no justification.

Legacy authentication enabled · MFA not enforced for all users · Broad admin roles without PIM · Guest access without expiration dates · No named location or device compliance conditions in CA

Block legacy authentication first. Enforce MFA with phishing-resistant methods where possible. Scope admin access through PIM with time-bound activation. Build Conditional Access policies tested in report-only mode before enforcement.

Legacy auth blocked for all users and apps · MFA enforced with no exclusions except documented break-glass · Admin roles assigned through PIM · CA policies in enforcement mode · Guest access reviewed with expiration

A tenant where legacy authentication is gone, MFA is enforced everywhere, admin access requires time-limited activation, and Conditional Access policies are tested and enforced.

Conditional Access changes that move too fast from design to enforcement are a common cause of production incidents. A bad CA deployment can lock out thousands of users or, worse, break the break-glass account.

Moving to enforcement without report-only review leads to unexpected blocks. Missing service account exclusions cause non-interactive authentication failures. Unlisted MFA methods block valid users.

No report-only phase · CA policy applied to all users immediately · Break-glass account not explicitly excluded · Service accounts affected by new policy · No sign-in log review before enforcement

Use report-only mode for at least one week. Review sign-in logs for unexpected blocks. Pilot with a small group. Verify break-glass exclusion. Enforce broadly only after pilot confirms no unexpected failures.

Report-only data reviewed with no unexpected blocks · Pilot group completed with no failures · Break-glass accounts excluded and tested · Service accounts accounted for · Policy in enforcement mode

A CA change that rolled out without blocking any legitimate access, with evidence from report-only logs and pilot validation.

Access permissions accumulate faster than they are removed. Stale accounts, overpermissioned roles, inactive guest users, and forgotten app integrations are common discovery targets.

Stale accounts with active credentials provide initial access for attackers. Guest users with persistent access create lateral movement risk. App integrations with write access bypass user-level controls.

Accounts with no sign-in in 90+ days still enabled · Guest users with access to sensitive resources and no review date · OAuth apps with write or directory access not reviewed in 12+ months

Disable before deleting. Assign ownership before revoking. Every account, guest, and app integration should have an owner, a business justification, and a review date.

No enabled accounts with 90+ days of inactivity · Guest access reviewed · App consent limited to actively used integrations · Role assignments have documented owners

An identity environment where every account, guest, and integration has an owner, a documented purpose, and a review date.

Most vulnerability management programs fail at the handoff from scanner output to remediation. The scanner finds hundreds of issues. Engineering receives a spreadsheet. Nothing gets fixed because everything is Critical.

Unvalidated scanner output wastes time on false positives. Missing business context means wrong things get prioritized. No ownership means no one acts. No retest criteria means closure is never confirmed.

Vulnerability backlog growing faster than closure · CVSS used as the only prioritization signal · No distinction between internet-facing and internal · Findings without assigned owners · No retest evidence in closed tickets

Validate exploitability before reporting. Add business context before prioritizing. Assign an owner before handing off. Define retest criteria before marking closed.

False positive rate documented · Each finding has one owner · Tickets include fix steps and retest criteria · Closure rate tracked by priority tier

A remediation program where every open finding has an owner, a fix path, a priority based on real exploitability, and a retest step that proves closure.

Most organizations do not have a clear picture of what is visible to an attacker before any credentials are used. DNS gaps, SSL issues, and exposed services are rarely reviewed as a unified surface.

Email authentication gaps enable phishing at scale. Misconfigured DNS enables cache poisoning. Exposed services provide initial access. Certificates without CAA controls allow unauthorized issuance.

No DMARC enforcement · SPF missing or soft fail · DNSSEC not enabled · CAA records not set · Shodan-indexed services on unexpected ports · Login pages without MFA prompts

Start from the outside. Enumerate what is visible without credentials. Validate what is genuinely reachable. Prioritize by realistic attack scenarios.

DMARC at p=reject · SPF with -all · CAA records set · DNSSEC enabled · No unexpected services exposed

An external attack surface where phishing is technically harder, DNS is tamper-evident, certificates are controlled, and exposed services are intentional.

AI tools are being adopted faster than security policy can follow. The result is unclear data flows, ungoverned model access, unreviewed vendor terms, and no process for deciding what AI use is acceptable.

Sensitive data enters AI tools without visibility. Vendor retention policies are rarely reviewed. DLP controls often do not extend to browser-based AI tools. Output influences decisions without human review.

No formal AI tool approval process · Users entering customer data into consumer AI tools · Vendor data retention not reviewed · No logging of AI tool usage · AI output acting on data without human sign-off

Start with data movement, not model behavior. Understand what enters each tool, where it goes, and what the vendor can do with it. Build approval tiers based on data sensitivity.

All AI tools are in the approved inventory · Vendor data handling reviewed · DLP coverage verified for high-sensitivity data paths · AI tool request process operational

An AI tool environment where every tool is approved, data exposure is bounded, vendor terms are reviewed, and output handling includes human checkpoints.

SaaS access accumulates without a lifecycle process. New users get access. Roles expand. Offboarding is inconsistent. The result is a large, unaudited attack surface.

Offboarded users with active SaaS credentials become orphaned accounts. OAuth apps with broad write access become privileged paths. Role creep leaves users with more access than their current job requires.

Offboarding checklist does not include SaaS revocation · OAuth apps with write access not reviewed in 12+ months · No role review for access that has expanded · Guest access without expiration dates

Every SaaS user needs an owner, a role justified by current job function, an offboarding step, and a periodic access review.

Offboarding includes SaaS revocation · OAuth app inventory current · No accounts active for offboarded employees · Quarterly access review completed

A SaaS environment where every active account matches a current employee, every OAuth integration has a documented owner, and access review is a repeatable process.

Code repositories are high-value targets containing source code, secrets, infrastructure configuration, and deployment pipelines. Most repository security problems are configuration issues.

Unprotected branches allow direct commits to production. Missing CODEOWNERS means no required reviewer. Secret scanning disabled. GitHub Actions with excessive permissions.

No branch protection on default branch · Push to main without pull request · No required reviewers · Secret scanning disabled · Workflow files with write permissions to all resources

Enforce code review for every change to protected branches. Require secret scanning. Restrict workflow permissions to minimum required. Add CODEOWNERS for sensitive paths.

Branch protection active on default and release branches · Secret scanning enabled · Workflow permissions defaulting to read · All environments require explicit access approval

A repository where every merge requires review, secrets cannot be committed accidentally, workflow permissions are minimal, and dependency changes are reviewed.

Recurring manual checks, noisy alerts, and repetitive triage tasks are candidates for lightweight automation. Good automation reduces cognitive load and makes security checks repeatable.

Manual checks get skipped when people are busy. Inconsistent processes produce inconsistent results. High-volume alerts without prioritization create fatigue and missed signals.

The same check being run manually more than once a week · A triage decision that follows a consistent rule most of the time · Alert volume that makes every alert feel low-value

Automate the repeatable part. Keep humans in the judgment loop. Build visibility into what the automation is doing. Make it easy to override or adjust.

Automation runs reliably on schedule · Output matches expected results · Override process documented and tested · False positive rate within acceptable bounds

A lightweight, documented automation that surfaces the right signals to the right people and does not require manual intervention to stay accurate.

Most security findings that go unfixed do not fail because the risk was unclear. They fail because the finding did not give the owner enough to act.

Without a specific fix, owners guess. Without a specific owner, nobody acts. Without retest criteria, closure is never confirmed. Without business context, urgency is not felt.

Findings with only a description and a CVSS score · No assigned owner on open findings · Fix steps that describe a concept instead of a specific change · No definition of what done looks like

Every finding handed to an owner needs: what is wrong, why it matters, how it was validated, what the specific change is, who owns it, and what a successful fix looks like.

Owner confirmed understanding · Fix implemented as specified · Retest criteria met · Finding closed with evidence

A finding that the assigned owner can act on without scheduling a meeting to clarify what security wants.