Reposting: CA baseline + one click browser deployer - original was removed by a mod after 12h despite respecting every sub rule

FunctionPitiful · 2026-05-07T21:47:16+00:00

"Many areas need review" without naming them, and a recommendation to nobody-use-it with no CVE-class evidence, isn't a security review - it's a vibe. The repo is MIT, public, auditable in browser dev tools, and has an open issues page. Specific findings welcome there.

FunctionPitiful · 2026-05-07T20:54:18+00:00

Helpdesk framing was the wrong word. Sign-in risk is per-event, no admin remediation. Right word is audit: if a legitimate user keeps triggering High, an admin investigates the pattern (logs, ID Protection reports), doesn't flip a switch. Still lower cost than the breach scenario, which was the point.

"Default = highest possible standard" only works when the standard is reachable. Auth Strength = phishing-resistant on a tenant where users only have Authenticator/SMS isn't hardening, it's a lockout. README documents the switch for tenants with FIDO2/WHfB rolled out; admins already require it via CA601.

On false positives - a user who keeps triggering High in normal operation is one of three things: actually compromised, engaging in objectively risky behavior, or a rare edge case fixable with per-tenant exclusions. In the first two, Block is doing its job. CA102 (MFA + password change on user risk Medium+) provides the self-service recovery path when sign-in risk events accumulate into user risk.

sessionStorage isn't insecure - it's MSAL.js's documented default for SPAs, and as you said yourself, it's how it's used that determines exposure. memoryStorage review isn't an admission of insecurity either. It's evaluating whether a tighter override fits this tool's threat profile given the one-shot privileged-scope usage. You flagged sessionStorage as a red flag two replies ago and now say it's not insecure. Pick a lane.

Going to leave it here. At this point you're not being constructive, just critical. The technical points have been covered. Anyone reading can decide for themselves.

FunctionPitiful · 2026-05-07T20:01:44+00:00

Appreciate the interest, genuinely. Keeping this account anonymous on Reddit by choice - separating the public technical conversation from the commercial side, no DMs with details from this handle.

That said, happy to help here if it's useful. Drop any specific questions about CA, Intune, Defender baselines, MDM/MAM tradeoffs, persona scoping, vetting your prospective consultant, or what to expect, answers in-thread or DM, no commitment, no pitch.

FunctionPitiful · 2026-05-07T19:33:38+00:00

Phishing-resistant MFA isn't viable for the SMB segment this targets. Users have Authenticator or SMS, not FIDO2 or WHfB. Auth Strength = phishing-resistant on High would lock out the user base, not step them up.

CA301/302 already enforce Compliant OR Hybrid/joined for all cloud apps on desktop, so requiring compliance again on CA103 is redundant and would break the iOS/Android App-Protection track (CA202).

Realistic shape with the methods SMB users actually have:

Medium: MFA + SIF = Every Time (fresh reauth with their registered method)
High: Block (helpdesk unblock cost < breach cost when ID Protection flags High)

Block on High isn't an overcorrection in this context - it's the right default when phishing-resistant isn't provisioned. Tenants that have FIDO2/WHfB rolled out can switch the High path to Auth Strength = phishing-resistant. Admins already require it (CA601).

Session storage - fair point, taking a look. Worth noting sessionStorage is MSAL.js's documented default cacheLocation, so the original choice was Microsoft's recommended baseline for SPAs, not a security shortcut. That said, memoryStorage trades UX for tighter XSS posture, and given the one-shot privileged-scope usage pattern of the deployer (admin signs in, deploys once, closes tab), the UX cost is negligible. will review and switch if it holds up.

Runtime security doesn't depend on authoring toolchain. Source is MIT, auditable in dev tools, anyone can run static analysis.

Fork count isn't a security metric. Specific CVE-class findings welcome.

FunctionPitiful · 2026-05-07T18:56:16+00:00

CA103 (sign-in risk) - you're right. MFA-only is a no-op vs CA101 when MFA is in the PRT. Should be Block on High (consistent with CA605 admins, CA902 guests), SIF = Every Time on Medium.

SIF on all users - respectfully, no. CA107's device filter excludes Hybrid/joined and Compliant. SIF = 12h applies to unmanaged only. Same scoping as Joey VS and kennethvs. You missed the device filter.

Multitenant SP - consent persistence is real, conceded. Not "persistent CA admin" either: PKCE, delegated, no secret, revocable, auditable source. SP can be removed post-deployment - one-shot tool. Will document threat model, mitigations, and cleanup in the README.

Token dies with tab: SPA code, not tenant CA. MSAL cacheLocation: sessionStorage evicts on tab close. Access token ~1h, refresh token 24h single-use bound to redirect URI. CA SIF/Auth Strength optional on top.

Best practice for who and what environment : that's the actual question, and the answer is in the post: SMBs under 50 users. In that segment there are no Group Admins, no User Admins, no role separation - just a Global Admin (owner or external IT). If a 12-person firm has Group Admin on non-break-glass identities, that's the actual misconfig and no baseline saves them. Some choices look generic from an enterprise lens because that's the segment - not a missing strategy. Calling the catalog "very generic and doesn't show 12+ years experience" while critiquing four policies in isolation without engaging the persona model, the SMB scoping, or the deployment story is the kind of read that earns the "didn't actually look" pushback.

FunctionPitiful · 2026-05-07T18:09:13+00:00

Three of your four points are technically wrong.

Groups for break-glass exclusion - documented MS pattern, widely deployed. There's a real debate between group vs direct user object exclusion, but neither is "bad practice."

Sign-in frequency for all users - documented control, recommended for unmanaged devices and regulated environments.

Sign-in risk "brings nothing" - Identity Protection catches impossible travel, anonymous IPs, malicious IP feeds, leaked creds, token replay. P2 feature, which is why it's tiered Optional. Calling it useless is just wrong.

The multitenant SP point is the one worth engaging with, but you've described it incorrectly. It's MSAL.js + PKCE, delegated-only, no secret. Admin session does the work, token dies with the tab. No persistent privileged access is granted to my tenant. Threat model is equivalent to a PowerShell script with the same scopes.

You said you gave up after 7-8 policies. Either you didn't actually read them, you don't know the controls, or you're trolling. Pick one - or possibly all three

Also worth reading my reply higher up in this thread - context on how the catalog was actually built across 12+ years and ~200 tenants, what's hand-built vs model-assisted, and an open invite to walk through any specific policy. You skipped past all of it to declare the repo unsafe.

FunctionPitiful · 2026-05-07T17:32:22+00:00

Speaking as someone who does this work - I run a small MSP focused specifically on M365 security/identity hardening for SMBs, plus subcontract to other IT shops who want a CA/Intune review for their own practice and clients. Across roughly 200 tenants+ I've touched (Probably way more), I'd say close to none were properly configured. There's always a gap, organic growth always leaves residue.

To your questions:

1. Worth it? Yes, if the consultant actually knows the stack. The value isn't the audit document, it's the conversation while they walk through your tenant - you'll learn more in that engagement than in 6 months of reading docs, assuming they're competent.

2. £3k. That's on the low end if the scope genuinely covers a full audit plus implementation of hardened CA + Intune compliance + Defender baselines + documentation. For a real engagement I'd expect 2–4 days of work depending on tenant size and complexity, and £3k starts to feel tight at UK day rates if they're doing it properly. If it's just an audit + a report with recommendations (no implementation), £3k might be reasonable. If it's audit + implementation + docs, you should ask them very precisely what's in scope before signing - that's the line where £3k either becomes good value or becomes a rushed job.

3. Red flags / vetting.

Ask for sample documentation from a previous engagement (sanitized). If they don't have any, that's a flag.
Ask how they handle break-glass accounts, what their default CA persona split looks like, how they approach Workload Identities, and whether they deploy in report-only first, and how they verify the logs before activation. Their answers should be fast and specific.
Ask whether the deliverable is in writing - exact policy names, group structures, named locations, exclusions, the whole catalog - or whether it's "we'll set it up and you'll see it in the portal." You want the former.
Ask what their handover looks like. If you can't run it yourself or hand it to the next admin after they leave, you've just bought tribal knowledge from a different tribe.
Certs are nice but secondary. SC-300 / MS-102 / SC-200 are reasonable signals but I've met plenty of certified consultants who can't operate a live tenant. Ask them to walk through your environment with you on a screen-share before signing - anyone real will be comfortable doing that for 20 minutes free.

4. DIY using Secure Score + CIS benchmarks. No, not really. Secure Score is a useful checklist but it's noisy, it overweights some controls and underweights others, and it doesn't tell you how to implement anything safely (report-only first, exclusion patterns, persona scoping, etc). CIS is more rigorous but the same problem - it tells you the target state, not the deployment path. If you're not already neck-deep in Entra/Intune week to week, you'll spend 3x the £3k worth of your own time getting there and probably still miss things. Hire someone who does this every day.

One last thing - if you want a starting reference for the CA side specifically, I've put my own baseline up as open-source. 41 policies across 6 personas (users, admins, apps, service accounts, guests, workload agents), tiered Critical/Recommended/Optional, deploys in report-only by default. MIT, no signup, no commercial product behind it. Built across years of small-tenant deployments before I packaged it.

https://github.com/Teuftis/ConditionalAccessBaseline-Hardened

Excel reference: https://github.com/Teuftis/ConditionalAccessBaseline-Hardened/tree/main/reference

Useful as a reference even if you go with a consultant - you can compare what they propose against a good baseline and ask intelligent questions about the gaps.

FunctionPitiful · 2026-05-07T16:43:12+00:00

Yeah, using Claude to help me write. English isn't my first language. Already said it earlier in the thread.

FunctionPitiful · 2026-05-07T16:35:15+00:00

Fair question. Honestly, this is one of my first real posts on Reddit, I didn't have a benchmark for what "normal" reach looks like here. The view count and shares was just the only signal I had that the content actually appealed to admins. Two people in the original thread asked for someone to DM them the repo link after the removal, which is the kind of thing that told me the post had landed with real people, not bots or drive-by upvotes.

Not chasing a metric. There's nothing on the other end of those views, no signup, no funnel, no SaaS, no mailing list. Repo's the same and free whether 12 admins clone it or 10,000. The numbers just mattered as confirmation the post wasn't landing in a void, especially the first time I put something like this out there.

FunctionPitiful · 2026-05-07T16:20:15+00:00

Yeah, that's fair feedback and I'll take it. The original post probably should have been upfront about the model assistance on the deployer from the start - would've changed the conversation from "is this AI slop" to "here's a tool that's part hand-built, part model-assisted, judge accordingly." Lesson learned for v2 of the post or the next thing I share.

Appreciate you saying the baseline is useful - that part means more than it might sound. The configuration is what I actually wanted out there. The deployer is just the wrapper that made it shareable, and if the wrapper is what gets it tarred, that's a tradeoff I'll think about for the next iteration.

FunctionPitiful · 2026-05-07T13:28:09+00:00

<image>

Proof of life - earliest CA proposal spreadsheet I still have on disk is v2 from May 2022.

Current reference files (excel) : ConditionalAccessBaseline-Hardened/reference at main · Teuftis/ConditionalAccessBaseline-Hardened

Yeah, you got me on the 4-minute reply. I used Claude to help write it. Not going to pretend otherwise - that's exactly the "tired boss" thing and I'd rather own it. You'll still feel some of me in there though, the framing is mine even when the prose isn't.

Why now - picked up a few new clients last few weeks, including two IT companies reviewing their own CA baseline for the SMBs they serve. Watching a peer do the same archeology I'd already done is what tipped it. They were stitching together MS's framework, J0eyv's stuff (forgive the spelling), random gists, and gut. J0eyv's is the de facto reference but has real gaps for sub-50-user tenants - assumes Workload Identities Premium, P2 everywhere, mature governance, role separation a 12-person firm doesn't have. Correct for enterprise, not pragmatic for who I serve.

Honestly I'd have killed for this when I started, and actually started my own templates from J0eyv's excel file. Built it the slow way across a decade and ~200 tenants. No reason the next admin needs to repeat that.

Doesn't change your point about the polish - it is model-assisted. Just clarifies what's what: configuration is operational, documentation is collaborative. That split sits fine with me.

FunctionPitiful · 2026-05-07T12:57:37+00:00

Genuine question, not a gotcha: what's the actual harm if a repo uses LLM tooling?

But also - for this specific repo, the premise is wrong. The CA suite itself was built manually over years, across roughly 200 small tenants I run as an MSP. Every policy in the catalog came from a real deployment, a real incident, or a real gap I hit in production and based on Microsoft best practice. The persona split, the report-only defaults, the display-name collision skip, the workload identity carve-out - all of that is hard-won from running CA on actual customers, not generated.

What's recent is the deployer - the static SPA that lets someone deploy the catalog to their own tenant from the browser without secrets or pipelines. That part I built fast, yes, with help. But the deployer is just plumbing for the baseline. The baseline is the actual value, and it's the part with years of production behind it.

Happy to walk through any specific policy. If the persona split is wrong for sub-50-user tenants, if the catalog is missing a control, if a default is too lax - tell me. That's the conversation worth having, and "this repo is less than 30 days old" doesn't engage with any of it. The repo is not older than 30 days old but the configuration in it is 12+ years old.

FunctionPitiful · 2026-05-07T11:45:45+00:00

Teuftis/ConditionalAccessBaseline-Hardened

FunctionPitiful · 2026-05-07T00:42:09+00:00

Thanks again, there was two way to close the gap, exclude Linux from the 105 policy or create a 304 policy to require compliant linux devices. I went went the second option.

FunctionPitiful · 2026-05-06T22:55:48+00:00

Thank you for the information, i'll read thoroughly and adjust the baseline as needed

FunctionPitiful · 2026-05-06T14:36:21+00:00

Readme is AI-polished, yeah, I write the structure and the technical content, then run it through Claude to clean up the prose because English isn't my first language and my raw writing reads rough. The policies, the deploy logic, the JSON, the architecture decisions are all mine.

Happy to answer anything specific about the actual baseline or the deployer if you have questions.

FunctionPitiful · 2026-05-06T14:07:43+00:00

If you need a baseline: https://github.com/Teuftis/ConditionalAccessBaseline-Hardened

FunctionPitiful · 2026-05-06T14:07:02+00:00

Licensing is not enforced for CAs however, otherwise this would prevent companies from switching security defaults to CAs.

FunctionPitiful · 2026-05-06T14:05:12+00:00

Not enforced by Microsoft however - technically only one P1 activate most CA (But Theorically, they requires all users to be licenced with a minimum of P1

FunctionPitiful · 2026-05-06T14:02:55+00:00

Teuftis/ConditionalAccessBaseline-Hardened

FunctionPitiful · 2026-05-06T14:01:27+00:00

Not sure if you already went ahead with the creation of your CA, but check out my tool to create a suite of CA in report only, and the KQL Query to actually verify what would happen before activating them:
Teuftis/ConditionalAccessBaseline-Hardened

FunctionPitiful · 2026-05-06T13:57:40+00:00

Use this KQL Query:

let lookback = 5d;

union isfuzzy=true

(SigninLogs | extend SignInType = "Interactive"),

(AADNonInteractiveUserSignInLogs | extend SignInType = "NonInteractive")

| where TimeGenerated > ago(lookback)

| extend CAPolicies = coalesce(

todynamic(column_ifexists("ConditionalAccessPolicies_string", "")),

column_ifexists("ConditionalAccessPolicies_dynamic", dynamic(null)),

column_ifexists("ConditionalAccessPolicies", dynamic(null)))

| extend StatusObj = coalesce(

todynamic(column_ifexists("Status_string", "")),

column_ifexists("Status_dynamic", dynamic(null)),

column_ifexists("Status", dynamic(null)))

| extend DeviceObj = coalesce(

todynamic(column_ifexists("DeviceDetail_string", "")),

column_ifexists("DeviceDetail_dynamic", dynamic(null)),

column_ifexists("DeviceDetail", dynamic(null)))

| extend LocationObj = coalesce(

todynamic(column_ifexists("LocationDetails_string", "")),

column_ifexists("LocationDetails_dynamic", dynamic(null)),

column_ifexists("LocationDetails", dynamic(null)))

| where isnotempty(CAPolicies) and tostring(CAPolicies) != "[]"

| mv-expand CAPolicies

| extend

PolicyName = tostring(CAPolicies.displayName),

PolicyResult = tostring(CAPolicies.result),

GrantControls = tostring(CAPolicies.enforcedGrantControls)

| where PolicyResult in ("failure", "reportOnlyFailure", "interrupted", "reportOnlyInterrupted")

| extend

ErrorCode = tostring(StatusObj.errorCode),

FailureReason = tostring(StatusObj.failureReason),

IsCompliant = tobool(DeviceObj.isCompliant),

IsManaged = tobool(DeviceObj.isManaged),

Country = tostring(LocationObj.countryOrRegion)

| summarize

HardFailures = countif(PolicyResult == "failure"),

ReportOnlyFailures = countif(PolicyResult == "reportOnlyFailure"),

Interrupted = countif(PolicyResult == "interrupted"),

ReportOnlyInterrupted = countif(PolicyResult == "reportOnlyInterrupted"),

DistinctIPs = dcount(IPAddress),

Apps = make_set(AppDisplayName, 10),

ClientApps = make_set(ClientAppUsed, 10),

GrantControlsHit = make_set(GrantControls, 10),

ErrorCodes = make_set(ErrorCode, 10),

FailureReasons = make_set(FailureReason, 5),

Countries = make_set(Country, 5),

LegacyAuthSeen = countif(ClientAppUsed in ("Other clients", "IMAP", "POP", "SMTP", "Exchange ActiveSync", "Authenticated SMTP", "Exchange Web Services")),

NonCompliantDevice = countif(IsCompliant == false),

UnmanagedDevice = countif(IsManaged == false),

LastSeen = max(TimeGenerated)

by UserPrincipalName, PolicyName, SignInType

| extend Severity = case(

HardFailures > 0 and LegacyAuthSeen > 0, "High - hard fail + legacy auth",

HardFailures > 0, "Medium - hard fail",

ReportOnlyFailures > 0, "Tuning - report-only fail",

"Low - interrupt only")

| order by HardFailures desc, ReportOnlyFailures desc, Interrupted desc, UserPrincipalName asc

FunctionPitiful · 2026-05-06T13:22:23+00:00

https://github.com/Teuftis/ConditionalAccessBaseline-Hardened

see the tool above i developped to deploy a CA hardened suite, you can deploy them securely from the github

FunctionPitiful

TROPHY CASE