1. The preparation is the work

By the time an alert fires, most of the outcome is already determined by what you set up beforehand: logging that actually captures what you'll need, access you can revoke instantly, backups you've tested restoring. You can't build these under pressure. Treat the calm periods as the real preparation.

2. Contain before you investigate

The urge to fully understand an incident before acting is natural and often wrong. If an account is compromised, disable it and revoke its sessions now; you can reconstruct the timeline after the bleeding stops. Containment buys you the time to investigate calmly.

3. Communication is half the job

A quiet, competent technical response that nobody can see reads, to a nervous organization, like nothing is happening. Give leadership a steady cadence of plain-language updates: what you know, what you're doing, what you need. It's not overhead — it's what keeps the response from being second-guessed.

4. Write it down as you go

A contemporaneous timeline — who did what, when, and why — is worth more than memory, both for the post-incident review and for any legal or compliance follow-up. Capture it live; you will not reconstruct it accurately later.

5. The review is where you actually get better

The point of a blameless post-incident review isn't to relive the bad day. It's to turn each incident into one or two concrete changes that make the next one smaller. An incident you don't learn from is just damage.

Originally published at athanasiuswahbah.com by Athanasius Wahbah.

Secure the risk, not the person

The instinct is to add friction everywhere. The better model is to spend friction where the risk actually is. A sign-in from a managed device on a known network is low risk; demanding step-up authentication for it just trains people to dismiss prompts. A sign-in from an unmanaged device in a new country is where the cost of a challenge is worth paying. Conditional Access is good at exactly this kind of targeting — use it for that, not as a blanket tax.

Make the compliant path the easy path

If the secure way to work is also the most convenient way, you've won. Device compliance, single sign-on, and passwordless authentication aren't just security features — they're the thing that makes "do it the right way" frictionless, which is what actually stops the workarounds.

Stage everything in report-only

Never ship a Conditional Access change straight to enforcement. Report-only mode tells you exactly who a policy would have blocked before it blocks anyone. The number is almost always larger and stranger than you expect — service accounts, legacy clients, an executive's travel pattern. Find those in report-only, not in a flood of help-desk tickets.

Leave a break-glass path

Every Conditional Access deployment needs excluded emergency-access accounts, monitored and tightly controlled. The day you lock yourself out of your own tenant is the day you learn why. Build the break-glass path first, test it, and alert on its use.

Originally published at athanasiuswahbah.com by Athanasius Wahbah.

Inventory what actually depends on AD

Before moving anyone, find what truly still needs the on-prem directory: legacy apps using LDAP or Kerberos, file shares, print, anything bound to a domain. Most of these have a cloud-native answer now, but you can't plan around dependencies you haven't enumerated. This step is unglamorous and it's where the whole project succeeds or fails.

Migrate in waves, with a rollback for each

Convert users in small cohorts, not all at once. Each wave should have a clean rollback so a surprise affects a handful of people for an hour, never the whole company for a day. The goal is that any single wave is boring.

Watch the identifiers

The sharp edges in identity migrations are almost always mismatched identifiers — how a user is keyed in the directory versus in downstream systems like MFA, single sign-on, and device management. A username that's a bare account name in one system and a full UPN in another will silently create duplicates or lock people out. Map the identifier flow end to end before you cut anyone over.

Give the help desk a tool, not a runbook

A migration generates a predictable set of support issues. Rather than handing the help desk a long document, give them a tool that diagnoses the common failures and tells them the fix. It turns a stressful cutover into a routine one and keeps the project moving at the pace of the people doing the work.

Originally published at athanasiuswahbah.com by Athanasius Wahbah.

The system of record should drive provisioning

The fix is to stop treating identity as something the help desk assembles by hand and start treating it as a function of the HR system of record. When HR marks someone hired, moved, or terminated, that event should flow automatically into the directory — Microsoft Entra ID in my case — and produce exactly the right group memberships, application access, and license assignment. No ticket. No interpretation.

Make access correct by default

The goal I aim for is "correct by default." A role and department, combined with a clear mapping to groups and applications, should fully determine someone's baseline access. Exceptions still exist, but they become the rare, reviewed case rather than the norm. The mapping itself becomes the thing you govern, instead of thousands of individual grants.

Offboarding is where the risk hides

Joiner automation gets the attention because it's visible and people feel the speed. But leaver automation is where the real exposure lives. An automated, immediate offboarding — disable, revoke sessions, reassign or preserve data, handle any legal hold — closes the window that manual processes leave open. Build this path first if you can only build one.

Build vs. buy

Commercial identity-governance platforms do this well, and at a certain scale they're the right answer. But they carry six-figure annual costs and significant implementation overhead. For many organizations, a focused integration between the HRIS and the directory delivers the lifecycle automation that actually matters at a fraction of the cost — and you own every line of it. That's the path I've taken, and it's held up.

Originally published at athanasiuswahbah.com by Athanasius Wahbah.

Start with what's actually core

Buy the things that are hard, commoditized, and not your differentiator — email, the operating directory, the database engine. Nobody should be writing their own identity provider. The question is only ever about the layer on top: the glue, the workflow, the integration that's specific to how your organization actually runs.

Three questions that decide it

• Does a product fit the workflow, or would we bend the workflow to the product? Bending the org to fit a tool is a cost most buyers never price in.
• What's the real total cost of the commercial option? License plus implementation plus the services to keep it configured. For a lot of governance and automation tooling, that's six figures a year and a multi-month rollout.
• Can a focused internal build cover the part that matters in weeks, not quarters? If the valuable 80% is a well-scoped integration, building it is often cheaper, faster, and a perfect fit.

The hidden asset: you own it

When you build, the institutional knowledge stays in-house, the roadmap is yours, and there's no renewal negotiation where leverage quietly shifts to the vendor. The flip side is real: you own the maintenance too. So build things that are stable in scope and central to your operation, and buy the things that churn or sprawl.

A bias toward building — with discipline

My instinct leans toward building, because the things I tend to need are exactly the org-specific glue that products fit poorly. But the discipline matters: build narrowly, document clearly, and be honest about what you're signing up to maintain. Done that way, an internal tool isn't technical debt — it's leverage.

Originally published at athanasiuswahbah.com by Athanasius Wahbah.