u/NathanSecurity

I'm trying to understand how people managing multiple Workspace tenants (MSPs, resellers, or anyone supporting several client domains) actually handle this in practice.

My understanding of the usual workflow is roughly:

• Log into each customer's admin console separately
• Repeat the same config changes tenant by tenant
• Handle onboarding/offboarding manually per domain
• Keep track of settings/policies in a spreadsheet or your own notes
• Write Apps Script or GAM scripts for anything repetitive

But I'm interested in what people actually do, not the documented ideal.

A few questions:

1. How many tenants do you manage, and how do you switch between them?
2. Do you use GAM, Apps Script, or the Admin SDK directly? For what specifically?
3. Have you built any internal tooling/scripts for this? What does it do?
4. Are you paying for anything (GAT+, Patronum, JumpCloud, something else)? What made you buy it, and what does it still not do?
5. What's the most repetitive thing you still do manually in each tenant one at a time?
6. How do you handle onboarding a new client tenant — how long does it take and what's the annoying part?
7. Do you have any way to see config drift across tenants, or check that a setting is consistent everywhere?
8. Is this actually painful, or is it fine once you've got your scripts sorted?

I'm particularly interested in real examples of what you do today, even if the answer is "I just log into each one, it's fine."

Not looking for product recommendations — trying to understand the actual workflow.

I'm trying to understand something from people who've actually had to run security/compliance at a smaller company (roughly 20–500 employees).

Enterprise companies have dedicated people for things like IAM, access governance, compliance, cloud security, vendor risk, security operations, etc.

Smaller companies obviously can't have a specialist for every one of these.

I'm curious what happens in practice.

For example, do you have someone manually doing things like:

• Access reviews / employee permissions
• Offboarding users across multiple SaaS tools
• Checking privileged/admin accounts
• Collecting SOC 2 / ISO evidence
• Maintaining security controls
• Proving that a security issue was actually remediated
• Reviewing SaaS/OAuth access
• Cloud security/configuration checks
• Vendor security reviews
• Security questionnaires from enterprise customers
• Maintaining compliance evidence
• Tracking exceptions and approvals
• Something else entirely

I'm especially interested in the things that technically have enterprise software available, but smaller companies still handle with spreadsheets, CSV exports, screenshots, scripts, or someone's memory.

A few questions:

1. What's the most annoying recurring security/compliance/IT process your company still does manually?
2. How often does it happen — weekly, monthly, quarterly, annually?
3. Who actually does it?
4. What tools/spreadsheets/scripts do you use today?
5. What happens if you don't do it properly or on time?
6. Is someone external actually requiring you to do it (auditor, customer, regulator, insurer, procurement/security team), or is it something you do internally?
7. Could you realistically satisfy the requirement with a spreadsheet + screenshots + manual work, or does that stop being sufficient at some point?
8. Have you tried automating it? If so, what didn't work?
9. Are there enterprise products that technically solve it but are too expensive/complex for your company?
10. If you could eliminate one recurring security/compliance task from your job tomorrow, what would it be?

I'm not looking for product recommendations or trying to sell anything. I'm trying to understand where smaller companies are essentially doing the work of an enterprise security team without the enterprise security team.

I'd particularly appreciate answers from people who have actually gone through SOC 2, ISO 27001, PCI, enterprise customer security reviews, or similar processes.

I'm curious how people building Microsoft 365 / Entra integrations handle this in practice.

Say you're building an application that makes a bunch of Microsoft Graph calls. You want to follow least privilege, so you need to determine the minimum delegated/application permissions the application actually requires.

How do you currently do this?

My understanding of the usual workflow is something like:

• Look up each Graph endpoint in the documentation
• Check the permissions table
• Use Graph Explorer to experiment
• Add permissions to the app registration
• Run into 403 / consent issues
• Add/remove permissions until everything works
• Periodically review whether you're requesting more than the application actually uses

But I'm interested in what people actually do, rather than the documented ideal workflow.

A few questions:

1. Do you determine permissions manually endpoint-by-endpoint?
2. Do you use any tooling to map your code/Graph SDK calls → required permissions?
3. Do you maintain a spreadsheet or internal documentation for this?
4. Have you ever discovered that an application was requesting significantly more permissions than it actually needed?
5. Have you ever had a deployment blocked because you discovered a missing Graph permission only at runtime?
6. If you're using Python/TypeScript/C#/Java SDKs, does your workflow differ?
7. Is this actually a painful problem for you, or is looking it up in the docs/asking an LLM sufficiently easy?

I'm particularly interested in real examples of what you do today, even if the answer is "I just look it up manually."

I'm not looking for product recommendations — I'm trying to understand the actual developer workflow here.

I'm curious how people building Microsoft 365 / Entra integrations handle this in practice.

Say you're building an application that makes a bunch of Microsoft Graph calls. You want to follow least privilege, so you need to determine the minimum delegated/application permissions the application actually requires.

How do you currently do this?

My understanding of the usual workflow is something like:

• Look up each Graph endpoint in the documentation
• Check the permissions table
• Use Graph Explorer to experiment
• Add permissions to the app registration
• Run into 403 / consent issues
• Add/remove permissions until everything works
• Periodically review whether you're requesting more than the application actually uses

But I'm interested in what people actually do, rather than the documented ideal workflow.

A few questions:

1. Do you determine permissions manually endpoint-by-endpoint?
2. Do you use any tooling to map your code/Graph SDK calls → required permissions?
3. Do you maintain a spreadsheet or internal documentation for this?
4. Have you ever discovered that an application was requesting significantly more permissions than it actually needed?
5. Have you ever had a deployment blocked because you discovered a missing Graph permission only at runtime?
6. If you're using Python/TypeScript/C#/Java SDKs, does your workflow differ?
7. Is this actually a painful problem for you, or is looking it up in the docs/asking an LLM sufficiently easy?

I'm particularly interested in real examples of what you do today, even if the answer is "I just look it up manually."

I'm not looking for product recommendations — I'm trying to understand the actual developer workflow here.

We're an MSP supporting multiple Microsoft 365 / Azure environments, and I'm trying to figure out how other teams are approaching the growing number of AI agents, service principals, OAuth applications and other non-human identities appearing in client tenants.

The questions we're starting to get from customers are things like:

• What agents/applications have access to our tenant?
• What Graph/API permissions have they been granted?
• Which identities are actually being used?
• Who owns or approved them?
• How do we identify excessive permissions?
• How do we deal with abandoned service principals or applications?
• Is there a practical way to revoke an agent's access quickly?
• How are you auditing this over time?

Microsoft gives us a lot of the individual building blocks through Entra, Defender, Graph, Conditional Access, PIM, etc., but I'm wondering whether there's a good way to manage this operationally across many tenants rather than doing tenant-by-tenant investigation.

For those already dealing with this:

What does your current workflow look like?

Are you using Microsoft-native tooling, CIPP/PowerShell, a third-party security product, or something you've built internally?

And do you consider AI-agent/NHI governance an actual problem today, or more of a problem you expect to have in the next 1–2 years?

I'm trying to understand what people are actually doing in production rather than what vendors are saying the future looks like.

Trying to get an honest read on this because the vendor stuff all assumes everyone's doing tidy quarterly app reviews, and that doesn't match what I've seen.

Realistically, across a book of tenants: does enterprise app / OAuth consent review actually happen on a cadence, or is it one of those things that's on the "should do" list but only gets touched when something looks off or a client asks?

If you do stay on top of it, I'm curious how — what's the setup that actually made it stick, versus staying a manual chore? And if you don't, is that because the tooling's painful, because clients don't care, or just because there's always something more urgent?

I ask because I'm building something in the M365 ops space and I'd rather find out I'm wrong about where the pain is than build for a problem nobody actually feels. Not pitching — genuinely trying to figure out if this is a real recurring headache or something I've overweighted. Happy to move to DMs if anyone would rather not talk client setups in public.

For anyone who's renewed cyber insurance recently or walked a client through underwriting — I'm trying to get a clearer picture of what insurers actually want to see, versus what they just ask you to attest to on the questionnaire.

From what I've run into so far, the questionnaire asks "do you enforce MFA," but the harder part is proving it — a "yes" checkbox is easy, an actual artifact showing MFA is enforced via Conditional Access (not just registered) is what seems to cause the back-and-forth. Same with privileged access: attesting is trivial, evidencing "we reviewed admin roles in the last X months" is where it gets awkward.

Curious whether that matches others' experience, or whether insurers are still mostly taking attestation at face value and the evidence demand only shows up at claim time.

And when they do ask for proof — is it screenshots, Secure Score exports, audit log pulls, something else? Trying to understand what actually satisfies an underwriter versus what just gets waved through.

I've noticed that most of the discussion around Entra security focuses on detecting issues, but much less on actually fixing them safely.

For those of you managing production Microsoft 365 environments:

What would have to be true before you'd trust a tool to automatically remediate security issues?

For example:

• Would you ever allow fully automatic remediation?
• Would you always want approvals?
• Would report-only mode be mandatory?
• How important are rollback, verification, and audit trails?
• Are there certain changes you'd never automate?

Im interested in the operational side of the problem rather than specific products.

i wanna where everyone draws the line.

I've been researching the Entra security ecosystem over the past few weeks (Maester, SCuBA, CIPP, Inforcer, Secure Score, Defender, and raw PowerShell/Graph scripting), and one thing I've noticed is that most of the discussion focuses on finding security issues.

What I haven't seen discussed nearly as much is what happens after you've identified them.

Asking because I keep seeing detection tooling get all the attention, but almost no discussion of safe rollout.

For those of you managing multiple tenants (especially MSPs and consultants):

• How do you safely roll out things like Conditional Access or identity configuration changes?
• Do you stage changes before wider deployment?
• Do you have approval/change-control processes?
• Have you ever had an automated change cause problems?
• How do you document or prove to a client exactly what was changed?

I'm less interested in which tool is best and more interested in what your real-world workflow looks like once you've decided a change needs to be made.

Is it mostly PowerShell/Graph scripts, commercial platforms, internal processes, or something else?

Curious to hear how people are actually handling this in production.

Curious what people here actually use for ongoing Entra ID security posture beyond the native Microsoft tools.

Mainly looking at things like MFA/CA posture, privileged and stale accounts, configuration drift, guest access, and keeping track of what changed over time.

I'm aware of Maester, ScubaGear, CIPP, Secure Score, etc., but what do you actually use in production?

Also curious how you handle remediation — do you trust any tool to make changes automatically, or mostly detect issues and fix them manually?

Detection patterns in Entra that are harder to get right than they look.

I've been building identity misconfig detection against the Graph API for a while and a few of these took way more iterations than I expected.

PIM: "eligible but never activated" isnt inherently bad, but "permanently assigned when PIM is available" almost always is. Distinguishing intent between those two states through the API alone was messier than I thought you end up inferring from role asignment type and activation history rather than any clean signal.

CA exclusions: checking "is CA enabled" is trivial; checking "does this policy still do anything given its exclusion list and named locations" is where the actual risk hides, and it's a lot harder to express programmatically.

External mail forwarding: still shockingly common, and Exchange Online doesnt make it easy to audit at scale.

Anyone got detection categories they've found genuinely hard to nail, or common misconfigs most tooling still misses?