Modern Workplace Mastery – Day 4: Baseline Tenant Security and Defaults
Turning CalderCloud’s Day 0 security promises into a practical, liveable baseline for sign-in protection, external sharing and basic auditing.
During the Day 0 workshop, CalderCloud’s leadership made some blunt commitments. They were tired of leaks caused by over-generous sharing links, unclear ownership, and ad-hoc “just make it work” admin changes. They were equally tired of staff living in a permanent state of low-level panic every time something in IT changed.
The promise wasn’t “install Microsoft 365 and hope for the best”; it was “design a modern workplace that is harder to misuse by accident, easier to run on purpose, and kinder on the people keeping it alive.”
This post is where those promises start to bite. We’ll decide whether CalderCloud leans on Microsoft’s Security Defaults safety net or graduates to a designed Conditional Access baseline; we’ll set how easy it is to share files and Teams spaces with people outside the organisation (in preparation for future posts on SharePoint, Teams and OneDrive); and we’ll make sure enough auditing and alerting is turned on that suspicious activity doesn’t vanish into the noise. The goal isn’t perfect security. The goal is a documented, defensible baseline that makes risky behaviour harder, not more tempting, and that a small admin team can actually operate.
As always, this post has two sections – the “TL;DR” section for those who just want a quick “slide” view and the “Detailed” section where the information is accurate (to 21st December 2025) and is written to give a reader the more definitive information – not short, but hey – I don’t write short summaries!! As it is Christmas – I say “On with the Show”.
I can imagine everyone thinking “OMG – this is going to be a long post” – and you are correct to assume that – so I figured I would do things a little different allowing you all to just read the bits you want to read – I take the “Accordion” and play around with tabs as well inside the accordion widget – hopefully this means you can all use the Table of Contents to help you navigate around easier.
Table of Contents
TL;DR – Modern Workplace Mastery - Safe by Default for CalderCloud’s Tenant
This TL;DR is a quick, overview of Day 4: the day CalderCloud moves from “we’ll secure it later” to a documented, safe-by-default baseline for identity, sharing and auditing.
You can scan it in a couple of minutes to understand:
- what decisions were made,
- what has actually changed in the tenant, and
- what you should do next if you’re responsible for running it.
If you’re short on time, start here so you can grasp the key decisions, baselines and outcomes in a couple of minutes. Once you’re ready to go deeper, you can scroll into the full post below or jump straight to a section using the Table of Contents.
Safe by Default: Baseline Security and Conditional Access Settings for the CalderCloud Tenant
A quick note on which accounts should touch the controls
CalderCloud’s Microsoft 365 tenant now exists, has a name, and has real people assigned to licences – but “switched on” is not the same as “safe to live in”. Over the first four posts in this Tenant Foundations arc, the organisation has gone from whiteboard sketches to a live tenant with a region, domains, a first admin account baseline and a sensible licensing Pattern.
That’s enough to let people sign in (when accounts are created) and send email. It’s not yet enough to say, with a straight face, that the new environment is safer and calmer than the old mess it’s replacing.
I keep the human perspective and impact front and centre. Stronger sign-in protection and safer sharing patterns can reduce password resets, access panics and last-minute “can you fix this now?” messages, but only if they’re introduced deliberately.
Badly designed controls just create more firefighting and more stress for everyone. Day 4 is about making “safe by default” feel like a calmer normal, not a new source of hassle.
Before we go anywhere near settings, I need to be clear about who should actually be doing the work in this post.
CalderCloud agreed back on Day 1 that there are four broad types of accounts in the tenant:
- Everyday user accounts – what staff use for email, Teams, SharePoint and normal work.
- Named admin accounts – separate identities for people like Jordan (the Modern Workplace Engineer / Sysadmin) who manage the tenant. These carry specific admin roles (for example, Security Administrator, Exchange Administrator etc.) and are always protected with strong Multi-Factor Authentication (MFA).
- Service / workload accounts – non-human identities used for automation, integrations and scheduled tasks (for example, application registrations, service principals, or carefully controlled “svc_” accounts). These should follow least-privilege rules, be documented with an owner, and avoid interactive sign-in wherever possible.
- Emergency “break-glass” accounts – very limited, highly protected accounts kept purely for recovering the tenant if Conditional Access (CA) or MFA ever misbehaves.
Who this post is for (reading lanes)
- End users / Curious Readers – You want to know what will change for you – more sign-in checks, safer file sharing, clearer signals when something looks off – without needing to learn every admin screen. You are not expected to become administrators or to run scripts. This post is here so you understand why you might see more MFA prompts, different link options or new security messages – not so you can promote yourself to Global Administrator.
- IT Leads and managers – You need to understand what you’re agreeing to and signing off: the level of risk we’re accepting, the trade-off between security and friction, and what good looks like for CalderCloud’s baseline over the next year. You are responsible for making sure only a small, trusted group have named admin accounts, that powerful roles like Global Administrator are used sparingly and intentionally, and that every service / workload account has a clear business owner and justification. If “just make this normal user a Global Admin” or “just create a mystery svc account with all the rights” is the only way a change will work, that’s a design problem, not a reasonable request.
- Sysadmins and tenant admins – You’ll be hands-on in (for example) Microsoft Entra ID, the Microsoft 365 admin centre, SharePoint, Teams and Microsoft Purview. This post gives you an opinionated starting configuration and a path from “Security Defaults” to a Conditional Access-driven baseline that you can actually run. You should perform all portal changes and PowerShell work using your named admin accounts, with the minimum roles needed for each task. Everyday user accounts should never be allowed to carry admin roles. Service / workload accounts should be created as proper application or workload identities wherever possible, given only the permissions they need, and excluded or specially handled in Conditional Access so they don’t become a back door. Global Administrator should be reserved for rare, clearly documented operations, ideally via time-bound elevation rather than being assigned permanently.
Whenever you see portal paths or PowerShell references later in this post, the assumption is always:
You’re signed in with a named admin account that has the right level of privilege for the job – nothing less, nothing more – and any service/workload accounts involved are explicitly designed, not improvised.
Bringing service and workload accounts into the picture here means the rest of Day 4 can talk about CA policies, legacy auth blocking and logging without silently encouraging “mystery svc accounts with god powers”, which is exactly the pattern we’re trying to retire.
Keeping those boundaries clear is part of CalderCloud’s “safe by default” posture. It protects the tenant, and it protects real people from waking up to find they’ve been made Global Admin by accident and are now one mis-click away from a very bad day.
Where We’re Starting From: CalderCloud’s Risk Posture and Day 0 Promises
Recap of Day 0 non-negotiables and “never again” moments
Day 0 at CalderCloud wasn’t a technical workshop; it was a therapy session for an organisation that had been burned before.
People arrived with stories. Projects that had stalled because no one knew who owned which system. Files shared with “anyone with the link” that quietly escaped into places they should never have been. Admin rights handed out as favours or shortcuts. Late-night “can you just fix it?” calls that became a way of life. None of it was uniquely terrible, but all of it added up to a constant background hum of risk and exhaustion.
Out of that came a set of “never again” statements that were deliberately plain:
- Never again – a tenant nobody really owns.
- Never again – mystery admin accounts with no clear human behind them.
- Never again – default-open sharing just because “it makes life easier”.
- Never again – pretending security will be “sorted later” once everything else is live.
- Never again – relying on heroic individuals working unhealthy hours as the main security control.
The board and senior leaders didn’t ask for a magic shield. They asked for something more boring and more useful: a baseline. A set of minimum conditions that had to be true about identity, access and collaboration before CalderCloud could claim their Microsoft 365 environment was any better than the sprawling mess they were leaving behind.
Day 4 is where that baseline starts to become real.
What Days 1–3 already locked in (tenant, domains, licences, account types)
By the time we reach Day 4, CalderCloud has already poured the foundations. We’re not starting with a blank portal.
Day 1 gave us a real tenant in the right place, with grown-up ownership:
- A single Microsoft 365 tenant created in the correct and agreed geo-graphical region.
- Named executive and technical owners, so “who is responsible?” is no longer a mystery.
- A small set of named admin accounts for people like Jordan, separate from their everyday user identities.
- At least one emergency “break-glass” account, documented and stored safely, in case Conditional Access or MFA ever misbehaves.
Day 2 stabilised domains and identities:
- A primary organisational domain chosen to last a decade, not a year.
- Sign-in addresses (User Principal Names), email addresses and display names aligned to that domain, instead of a random mix.
- DNS records pulled under proper control, with old “freebie” or experimental domains either retired or parked on purpose.
This matters for security. When you know what “normal” addresses look like, it’s easier to spot the odd ones. When there’s a single, well-managed domain, admin policies and audit logs make more sense.
Day 3 tackled licensing as an architectural decision rather than a shopping list:
- A small number of licence patterns matched to real roles – not dozens of one-off combinations.
- Core employees on plans that include Entra ID Premium Plan 1 capabilities, opening the door to Conditional Access.
- Lighter-use (often referred to as frontline workers) staff on more modest plans, with a conscious decision about how far baseline protections will apply to them.
- Early recognition that some non-human workloads will need their own identities – service / workload accounts – rather than being hacked on to someone’s user account.
By the end of Day 3, CalderCloud has four clear identity families in the tenant:
- Everyday user accounts – normal staff identities.
- Named admin accounts – separate admin identities with specific roles.
- Service / workload accounts – designed non-human identities for automation and integrations.
- Emergency “break-glass” accounts – last-resort access in case a policy goes wrong.
Day 4 builds directly on that. We’re no longer asking “what sort of tenant do we have?” We’re asking “given who we are and what we’ve already decided, how safe is this thing by default?”
Why we’re doing security and sharing baselines before anything “fun”
It’s tempting to start a Microsoft 365 project with the shiny bits: a fresh intranet, better Teams channels, maybe a Copilot pilot.
CalderCloud has deliberately chosen a less glamorous path: security and sharing baselines first.
There are two reasons:
First, the defaults in Microsoft 365 are powerful. If you do nothing:
- Users can often share files very widely, very quickly.
- External guests can be added with a couple of clicks.
- Basic sign-in may “just work” on older clients and devices in ways that quietly sidestep modern protections.
That’s fantastic for productivity in a low-risk, low-regulation environment. It’s much less fantastic if your recent history includes accidental leaks, uncomfortable auditor conversations, or staff nervously asking “Is it safe if I…?”
Second, CalderCloud is serious about people, not just settings. Jordan and Sam (You will officially meet these employees in a later post) are already doing a lot; they can’t sustain a life of constant firefighting. If the organisation launches branding, intranets and new collaborative spaces on top of a wobbly identity and sharing setup, incident volume will creep up and the pressure will follow.
So the Tenant Foundation arc insists on this order:
- Create a tenant you actually own.
- Stabilise names and licences so identities make sense.
- Design and document a “safe by default” baseline for sign-in, sharing and logging.
- Only then start layering on the fun stuff.
That doesn’t mean nothing useful happens until every possible control is in place. It means there is a minimum floor below which CalderCloud won’t drop: no wide-open sharing “because it’s easier”, no anonymous legacy protocols quietly kept alive “because that one printer needs it”, no admin work done from everyday accounts “because it’s quicker”.
Day 4 is about drawing that line clearly, with enough care that people can live with it. Importantly by the end of Day 4, CalderCloud will have a clear, signed-off baseline for identity protection, external collaboration and essential audit coverage – the security floor the organisation is never willing to fall below again.
What “Safe by Default” Means for a Small-but-Serious Organisation
Principles: least privilege, assume breach, verify explicitly, minimise surprise
“Safe by default” at CalderCloud isn’t a random checklist; it’s a translation of Zero Trust ideas into something a modest UK organisation can actually live with. Microsoft’s Zero Trust model boils down to three core principles: verify explicitly, use least-privileged access, and assume breach. CalderCloud adds a fourth, very human one: minimise surprise.
- Use least privilege
Every identity whether user, admin, service, guest, even future AI agents, should have the minimum access needed, for the shortest reasonable time. In Microsoft Entra ID that means role-based admin access, group-based permissions for Teams and SharePoint, and avoiding “Owner of everything” patterns. It also means service / workload accounts, app registrations and “svc_” accounts are tightly scoped instead of being given blanket rights “just in case”. - Assume breach
Zero Trust explicitly tells us to design as if something will eventually go wrong. CalderCloud leans into that by treating MFA, Conditional Access and strong defaults as basic hygiene, not optional extras. Admin accounts are treated as likely targets; guest accounts are assumed to sit on unmanaged devices; legacy protocols are treated with suspicion until proven necessary and carefully sandboxed. - Verify explicitly
Instead of trusting anything inside the network by default, every access request is checked using identity-driven signals: who you are, where you are, what you’re using, how risky it looks. Microsoft Entra Conditional Access is literally described by Microsoft as the Zero Trust policy engine enforcing those decisions. - Minimise surprise
CalderCloud adds this because humans break under too many unexplained changes. A security baseline that constantly ambushes staff with new prompts, blocks and errors is a security incident waiting to happen. The rule is: fewer, clearer controls that behave consistently and are explained before they cause incidents. That reduces the “security fatigue” and burnout that research keeps flagging in IT and security roles.
For Day 4, “safe by default” means these principles show up in defaults, not often typically poor managed edge-cases: the default link type is safe; the default sign-in path is strongly protected; the default logging stance is “on”, not “we’ll enable it when something breaks”.
CalderCloud constraints: budget, licences, IT capacity and mental load
CalderCloud doesn’t have the budget or headcount of a global bank, and pretending otherwise would give them a security architecture they can’t operate.
On the licensing side:
- Most information workers are on plans that include Microsoft Entra ID Plan 1 (P1) – for example, Microsoft 365 Business Premium – which unlocks Conditional Access.
- Some frontline or low-usage roles are on lighter licences without all the bells and whistles.
- Not every user or service can justify premium add-ons such as advanced threat hunting or full device compliance enforcement from day one.
That means CalderCloud can use Conditional Access as the backbone of its identity baseline, but it must do so selectively and licence-compliantly, not by blindly targeting “All users” and hoping for the best.
On the tooling and operations side:
- There is a central Security Operations Centre (SOC) at group level, but no separate CalderCloud-only Security Information and Event Management (SIEM) team with its own dedicated analysts.
- The Microsoft 365 tenant is expected to provide good-quality logs, alerts and baselines that the central SOC can consume, while Jordan and Sam handle day-to-day hygiene inside the tenant.
And then there’s human capacity and mental health:
- Studies keep finding high rates of stress and burnout among cybersecurity and IT professionals, especially where workload is high and expectations are vague.
- CalderCloud has already decided it will not build a modern workplace that depends on people quietly absorbing endless extra work and anxiety.
So the Day 4 baseline has to fit into a world where:
- A small team can operate the controls consistently.
- The central SOC gets enough signal from the tenant to do its job.
- People get less firefighting over time, not more.
That’s why this post focuses on a small number of high-value controls (identity, sharing, logging) that CalderCloud can actually sustain, rather than a shopping list of every possible security feature Microsoft offers.
Deciding what belongs in the initial baseline vs later maturity stages
With principles and constraints on the table, CalderCloud has to resist a classic trap: trying to implement “Zero Trust for everyone, everywhere” in one go.
Instead, Day 4 defines a clear split between:
- The initial baseline – things that must be in place before CalderCloud rolls out Microsoft 365 widely; and
- Later maturity stages – important but heavier capabilities that will be tackled in future topics and posts.
The initial baseline for Tenant Foundations – Day 4 covers three pillars:
- Identity protection
- A deliberate choice between Security Defaults and a Conditional Access baseline, with CalderCloud opting for the latter because it has Entra ID P1 and real external collaboration needs.
- MFA applied in a consistent, understandable way for staff, admins, guests and service accounts.
- Stronger protections for high-value admin and break-glass identities.
- External collaboration defaults
- Tenant-wide external sharing levels for SharePoint and OneDrive set to “sensible, not scary” – no more “Anyone with the link” as the everyday default.
- Teams external and guest access aligned with that stance, instead of being an afterthought.
- Core logging and alerting
- Unified auditing enabled and verified.
- Mailbox auditing confirmed where licences require it.
- A small set of high-value alerts tuned so CalderCloud and the SOC see the big problems (risky sign-ins, mass downloads, new admins) without drowning in noise.
Everything else goes into later maturity stages, not the bin:
- Richer Data Loss Prevention (DLP) policies, sensitivity labels and full records management.
- Device compliance enforcement and conditional access based on device health.
- More advanced Defender features, insider risk controls and detailed framework mapping (Cyber Essentials Plus, ISO 27001, etc.).
Those capabilities are absolutely in scope for the series, but they belong in future topics once the Day 4 baseline is in place. This mirrors how Microsoft itself talks about Zero Trust as a journey: start with identity and basic protection, then expand across devices, apps, data and infrastructure.
By making this split explicit, CalderCloud avoids two bad outcomes:
- Over-promising – claiming to be “Zero Trust” on paper while running an unmanageable tangle of half-finished controls.
- Under-delivering – leaving the tenant on vague defaults because “doing it properly” feels impossibly big.
Day 4’s job is to land a baseline that is understandable, supportable and signed off, while clearly flagging which ambitions are deliberately parked for later rather than quietly forgotten.
- You don’t need to memorise “Zero Trust”, “Conditional Access” or “Baseline Security Mode”. What matters is that the defaults are being set so it’s harder for you to accidentally leak data or fall for something nasty, and easier to know what “normal” looks like.
- When later sections talk about more prompts or stricter sharing options, this is the logic behind them; it’s not punishment, it’s guard rails.
- You’re not being asked to fund or operate bank-grade security from day one. You are being asked to approve a clear minimum standard for identity, sharing and logging that fits your budget and headcount.
- The “baseline vs later maturity” split is your friend: it gives you a roadmap instead of a bottomless to-do list, and it gives you language to use with the board about where CalderCloud is now and where it will be in 12 months.
- This section is your architectural brief. It defines the shape of what you’ll build: Conditional Access as the policy engine, safer sharing defaults instead of “Any link”, logging that actually lets you answer “what happened?” without tears.
- It also protects you: by acknowledging licence limits, security expectations and mental load, it gives you a defensible answer when someone says “Can’t we just turn everything on?” – the answer is “Not without breaking the baseline we agreed here.”
From Security Defaults to a Conditional Access Baseline
Security Defaults, Conditional Access and Baseline Security Mode: the lay of the land
In Microsoft Entra ID (Entra ID), there are two main ways to get a solid identity baseline without inventing everything from scratch:
- Security Defaults – a “one-switch” safety net for sign-in security, aimed at organisations that don’t have premium identity licensing or the time to design policies. Microsoft’s own guidance shows it is enabled/disabled from Entra ID → Overview → Properties → Manage security defaults.
- Conditional Access (CA) – Entra ID’s policy engine (Microsoft describes it as the Zero Trust policy engine) where you define who can access what, under which conditions, and whether they must use Multi-Factor Authentication (MFA) or be blocked.
The key behaviour that often confuses people is this:
Security Defaults and Conditional Access aren’t meant to run together.
If you create or use Conditional Access policies, Entra ID effectively treats Security Defaults as “replaced”, and you may find the “Manage security defaults” toggle is unavailable or disappears. Microsoft explicitly states that Conditional Access and Security Defaults aren’t meant to be combined, and creating Conditional Access policies prevents enabling Security Defaults.
Now add the third option:
- Baseline Security Mode (BSM) – a Microsoft 365 admin centre feature that helps apply a set of recommended security settings across Microsoft 365 services (not just identity). It can be found in Microsoft 365 admin centre → Settings → Org settings → Security & privacy → Baseline Security Mode.
A simple overview that stops this becoming alphabet soup:
- Security Defaults = basic identity seatbelt (simple, limited knobs).
- Conditional Access = the adjustable safety harness (more control, more responsibility).
- Baseline Security Mode = tunes the rest of the car so the harness works consistently (sharing, access and service defaults aligned across Microsoft 365).
For CalderCloud on Day 4, the practical goal is not “pick a favourite feature”. It’s: decide what replaces Security Defaults (Conditional Access), then use Baseline Security Mode to help align the wider tenant to the same posture
When Security Defaults are “good enough” and why CalderCloud is moving on
Security Defaults are genuinely fine for some organisations. They’re designed to raise the floor for tenants that lack Entra ID premium licensing and don’t have the time or confidence to design Conditional Access policies.
Security Defaults are often “good enough” when:
- The organisation is small and access patterns are simple.
- There are few external guests and few integrations.
- There’s no Entra ID Plan 1 (P1) licensing coverage to support Conditional Access broadly.
- The priority is “turn on something sensible” rather than “design a tailored baseline”.
CalderCloud doesn’t fit that profile anymore (and that’s a good sign of maturity, not complexity for complexity’s sake):
- CalderCloud has a licensing shape that supports Conditional Access for many users.
- It has real external collaboration needs (guests, partners, real project work).
- It has four identity families to account for: everyday users, named admins, service/workload identities, and break-glass accounts.
- It must keep the tenant understandable and supportable for a small local team, while producing predictable signals for a central Security Operations Centre (SOC) and any existing Security Information and Event Management (SIEM) tooling.
So CalderCloud makes a deliberate choice: we “graduate” from Security Defaults to an effective, well-documented Conditional Access baseline that explicitly replaces what Security Defaults were giving us, but with the control we need.
Designing CalderCloud’s Conditional Access baseline: the policy set and scope
This is where we stop talking in slogans and define an identity baseline a real sysadmin can operate.
Microsoft now provides Conditional Access policy templates, organised into categories (including Secure foundation and Protect administrator) and recommends these as a base for all organisations.
CalderCloud’s baseline will start small and boring-on-purpose. The aim is clarity, not policy sprawl.
Baseline policy set (minimal, defendable):
- Require MFA for all staff sign-ins
Applies to standard staff accounts (scoped via group membership where needed).
Outcome: users must complete Multi-Factor Authentication (MFA) when accessing cloud apps. - Harden admin access (privileged roles)
Applies to admin roles and named admin accounts.
Outcome: MFA is always required, and the bar can be raised later (for example, phishing-resistant methods) without changing the whole tenant. - Block legacy authentication
Blocks older authentication methods that don’t support modern controls.
This is one of the most important “quiet wins” in reducing account compromise risk. - Require MFA for guests (external collaboration)
Applies to guest identities accessing CalderCloud resources.
Outcome: external collaboration stays possible, but isn’t casually wide open. - Protect security information registration
Ensures people can’t casually change authentication methods without appropriate checks (this is a common “account takeover” pathway). - Protect device join/registration (where in scope)
Controls who can join/register devices and under what conditions (kept light in Topic 1; we go deeper in the identity/devices topics later).
Scoping rules (this is where mistakes usually happen):
- Break-glass accounts are excluded from all Conditional Access policies.
They exist for when policy goes wrong. If you include them, you’re building a lockout trap. - Service / workload identities are handled explicitly, not improvised.
Wherever possible, use non-interactive application identities (for example, app registrations / service principals) rather than “mystery svc accounts” with interactive sign-in. If a workload must sign in, it gets its own scope and justification, not a silent exception buried in a policy. - Keep the first baseline policy count low.
The more policies you create, the harder it is to reason about “why was this sign-in blocked?”. CalderCloud wants policies they can explain on a whiteboard.
That’s the design charter. Next comes the question every tenant admin cares about:
how do we land it without breaking everyone’s Monday morning?
End Users / Curious Readers
- You may see more consistent sign-in checks (for example, an MFA prompt) when accessing Microsoft 365 apps.
- Guests you invite into files or Teams spaces may be asked to prove who they are with MFA.
- The aim is not to make life harder; it’s to stop “one compromised password” becoming “everyone’s data is exposed”.
IT Lead / Management
- Your “sign-off” decision is essentially: we’re moving from a generic safety net to a designed identity policy baseline.
- Expect a small, manageable amount of short-term friction (a few MFA set-up questions, some “why can’t I use this old mail client?” noise) in exchange for a very large reduction in long-term risk and firefighting.
- The success measures you should care about are practical: lockout rate, support ticket volume, number of risky sign-ins caught early, and whether the admin team’s stress levels trend down rather than up
Implementation Steps: Moving from Security Defaults to Conditional Access
This is the high-level sequence CalderCloud follows to move safely from Security Defaults to a Conditional Access baseline.
Phase 0 – Preconditions (do not skip these)
- Confirm break-glass accounts exist and work.
Test sign-in with the account(s) in a controlled way and confirm the credentials are stored securely. - Confirm named admin accounts are separate from everyday user accounts.
Admin activity should not happen from normal user accounts. - Identify service / workload identities and owners.
List any automations, integrations, applications, third-party tools and scripts that sign in today. - Confirm Entra ID Plan 1 (P1) coverage for users in scope.
Conditional Access requires appropriate licensing for targeted users.
Phase 1 – Capture current state (so you can prove what changed)
- Check whether Security Defaults are enabled (if visible) via Entra ID → Overview → Properties → Manage security defaults.
- Note: if your tenant already has Conditional Access policies, Security Defaults may not be available to manage. That’s expected behaviour.
Phase 2 – Build the Conditional Access baseline in report-only mode
- Go to Entra ID → Conditional Access → Policies.
- Create the baseline policies (from templates if appropriate) and set each policy to Report-only. Microsoft explains that report-only evaluates policies during sign-in but doesn’t enforce them.
- Scope carefully:
- Include pilot groups first (IT + a small cross-section of users).
- Exclude break-glass accounts.
- Handle service / workload identities explicitly (separate group, documented exceptions).
Phase 3 – Observe impact (prove it before you enforce it)
- Use Entra ID → Monitoring & health → Sign-in logs to inspect sign-ins and see how Conditional Access would have applied.
- In individual sign-in details, review the Conditional Access evaluation (including report-only results). Microsoft notes these results appear in sign-in log details.
Phase 4 – Fix the “surprises”
- Common findings in this phase include:
- a legacy client still using legacy authentication,
- a third-party integration that needs a more appropriate workload identity,
- a guest workflow that needs clearer comms and guidance.
- Resolve by design, not by panic:
- move the workload to an app registration / service principal where possible,
- time-box any exceptions,
- document the “why” so it doesn’t become permanent folklore.
Phase 5 – Enforce in stages (no cliff edges)
- Switch policies from Report-only to On for the pilot group first.
- Expand scope in deliberate waves (for example: IT/admins → pilot users → all staff → guests).
- Keep monitoring sign-in logs and support tickets during each wave.
Phase 6 – Retire Security Defaults (only when CA is proven)
- If Security Defaults are still visible, disable them in Entra ID → Overview → Properties → Manage security defaults, and save. Microsoft’s Security Defaults guidance includes explicit steps for disabling when replacing with Conditional Access.
- If Security Defaults are not visible because Conditional Access is already in use, treat Security Defaults as already “replaced” and focus on ensuring your CA baseline fully covers the protections you want.
Phase 7 – Align Baseline Security Mode to support the same posture
- Go to Microsoft 365 admin centre → Settings → Org settings → Security & privacy → Baseline Security Mode (BSM).
- Use BSM to align broader Microsoft 365 settings (for example, collaboration defaults) so they don’t undermine your identity baseline.
Phase 8 – Document and operationalise
- Record in the charter:
- policy names, scope and intent,
- exclusions (especially break-glass and workload identities),
- your exception process,
- what the SOC/SIEM team should expect to see,
- the review rhythm (weekly/monthly checks).
This is how CalderCloud turns “safe by default” from a one-off configuration sprint into something the organisation can actually sustain.
Important – Please be aware that you may not have used the admin portal in great detail to this point – yes feel free to go look and find the area you need to be in, but know that future posts will be delving deeper into this area with greater detailed step-by-step information. For now it is added so that you have visibility of the relevant pages / sections that will be covered in this post.
- You now “own” an actual policy set, not a single toggle. That means:
- you can be precise (admins and guests don’t have to be treated the same as everyone else), and
- you must operate the baseline (exceptions, testing, monitoring, documentation).
- The baseline is designed to be small enough to run, and structured enough that it plays nicely with SOC/SIEM expectations later (logs make sense, changes are traceable, exceptions are documented).
PowerShell verification and automation: proving the baseline (without living in the portal)
The portal steps in the End User tab are the safest way to change identity settings, especially when you’re moving from Security Defaults to Conditional Access (CA). But once the baseline exists, you need a way to verify, report, and monitor it repeatedly without clicking through ten policies every week.
This is where PowerShell comes in – as discussed in an earlier post, this content is directed at Sysadmins that are familiar and understanding of PowerShell and its connectivity with a Microsoft 365 Tenant; specifically Microsoft Graph (the Microsoft Graph PowerShell Software Development Kit (SDK)), which talks to Microsoft Graph (Microsoft’s application programming interface (API) for Microsoft 365 and Entra ID).
Just as importantly, PowerShell supports CalderCloud’s “safe by default” account model: you can run read-only checks using least privilege, and you can automate reporting using non-user identities (service / workload accounts) rather than borrowing someone’s interactive admin session.
Read-only “baseline evidence pack” (recommended first)
These commands are deliberately read-only: they help you document what you have, and spot early problems, without changing anything.
Prerequisites (PowerShell session):
# Install the Microsoft Graph PowerShell SDK (once per machine/user)
Install-Module Microsoft.Graph -Scope CurrentUser
# Connect using least-privilege delegated permissions for reporting
Connect-MgGraph -Scopes “Policy.Read.All”,”AuditLog.Read.All”
The Get-MgIdentityConditionalAccessPolicy cmdlet retrieves Conditional Access policies.
# Export Conditional Access policies (human-readable + raw)
$policies = Get-MgIdentityConditionalAccessPolicy -All
$policies | Select-Object DisplayName, State, Id | Sort-Object DisplayName | Export-Csv “.\CA-Policies.csv” -NoTypeInformation -Encoding UTF8
$policies | ConvertTo-Json -Depth 25 | Out-File “.\CA-Policies.json” -Encoding UTF8
Now, pair that with sign-in evidence. Get-MgAuditLogSignIn retrieves Microsoft Entra sign-in events (sign-in logs).
# Look for recent Conditional Access failures (example: last 24 hours)
$start = (Get-Date).ToUniversalTime().AddHours(-24).ToString(“o”)
$failures = Get-MgAuditLogSignIn -All -Filter “createdDateTime ge $start and conditionalAccessStatus eq ‘failure'”
$failures | Select-Object CreatedDateTime, UserPrincipalName, AppDisplayName, ConditionalAccessStatus |
Export-Csv “.\CA-Failures-Last24Hours.csv” -NoTypeInformation -Encoding UTF8
A useful nuance: the appliedConditionalAccessPolicies details in sign-in log responses may be omitted if the identity/app doesn’t have permission to read Conditional Access data. That’s a feature, not a bug — and it’s why we treat permissions as part of the baseline design. (Microsoft Learn)
Safer admin practice: avoid “Global Admin in PowerShell” habits
CalderCloud’s baseline is explicitly trying to prevent “everyday user becomes Global Administrator (GA) so they can run a script”.
A better pattern is:
- Use a dedicated admin identity for PowerShell work (separate from normal email /Teams use), and lock it down with Conditional Access.
- For repeatable automation, use an app registration / service principal with pre-consented permissions, or a managed identity where supported – so you’re not relying on a human login at all.
That approach reduces privilege creep, improves audit clarity, and prevents “someone left a powerful token lying around” disasters.
Optional: managing policies via PowerShell (use with care)
Yes, you can create and update Conditional Access policies with Graph PowerShell (for example New-MgIdentityConditionalAccessPolicy and Update-MgIdentityConditionalAccessPolicy).
But for Day 4 we keep the “create policies” work portal-led (safer change control), and use PowerShell primarily for export, verification and reporting. That keeps the baseline stable while still giving Sysadmins the operational tooling they expect.
Baseline Sign-in Protection for Admins, Users and Non-User Accounts
Multi-Factor Authentication for staff and guests: what we require and how people onboard
For CalderCloud, Multi-Factor Authentication (MFA) is not a “nice to have”. It’s the minimum bar for day-to-day sign-in safety, because passwords alone are cheap, reusable and endlessly phishable.
The trick is doing MFA in a way that’s both secure and liveable.
Microsoft’s current guidance strongly favours phishing-resistant methods (methods that can’t be replayed by an attacker through a fake sign-in page), such as Windows Hello for Business, passkeys (Fast IDentity Online 2 (FIDO2)), FIDO2 security keys, and certificate-based authentication (CBA).
CalderCloud won’t force phishing-resistant methods for every user on day one, but it will design towards them and absolutely prioritise them for admins and emergency accounts.
User onboarding experience (what people will actually do):
- CalderCloud uses combined registration so users register security information once for both MFA and Self-Service Password Reset (SSPR).
- Users will be nudged via an MFA registration campaign (a gentle “please set this up” experience) rather than relying on tribal knowledge and a support ticket surge.
- End users are guided to the “Security info” area in My Account, where they add sign-in methods (for example Microsoft Authenticator, passkeys).
For guests (external users), CalderCloud takes a simple baseline stance: guests must use MFA when accessing CalderCloud resources, enforced via Conditional Access (CA). Microsoft provides explicit guidance and examples for requiring MFA for “All guest and external users”.
Where practical, CalderCloud will also take advantage of the ability to trust MFA claims from other Microsoft Entra tenants (so a well-managed partner tenant’s MFA can satisfy requirements), which reduces friction without reducing standards.
Finally, CalderCloud uses Temporary Access Pass (TAP) as the “safe recovery / onboarding bridge” for users who need to register stronger methods or recover access without helpdesk heroics. TAP is an Entra ID authentication method specifically designed for onboarding and recovery.
Extra protection for admins and emergency “break-glass” accounts
Admins are not “power users”; they are high-value targets. CalderCloud treats admin sign-ins as a different species of risk, and applies stronger requirements accordingly.
Named admin accounts
- All admin work is performed using separate named admin accounts (not everyday user accounts).
- Admin roles are assigned on a least-privilege basis (for example, Conditional Access Administrator, Authentication Policy Administrator) and Global Administrator is reserved for rare, documented actions.
Emergency access (“break-glass”) accounts
Microsoft’s own guidance is unambiguous: create two or more emergency access accounts so you can recover if everyone else is locked out.
Those accounts should be cloud-only, not tied to any one person’s phone, and protected with strong, resilient methods. Microsoft recommends passkeys (FIDO2) (or certificate-based authentication if you already have a Public Key Infrastructure (PKI)), and it explicitly calls out monitoring and regular validation drills.
This is the “CalderCloud nuance” that keeps us honest:
- Break-glass accounts are excluded from Conditional Access policies (to avoid policy misconfiguration causing total lockout).
- Break-glass accounts are not “weaker” accounts. They are protected differently: strong authentication, stored credentials, dedicated secure workstation access, aggressive monitoring/alerting, and regular drill sign-ins to prove they still work.
That pattern gives CalderCloud a safety rope without turning it into a back door.
Practical warning: if you allow too many “fallback” authentication methods for privileged accounts, attackers can sometimes force a downgrade to weaker options. Keeping admin methods tight is part of why we later move towards phishing-resistant authentication strengths.
Service and workload identities, legacy apps, and other awkward edge cases
This is where tenants quietly fail: a perfectly reasonable Conditional Access baseline gets undermined by “just one integration” that ends up with god-mode credentials.
CalderCloud’s rule is simple:
- Use workload identities (app registrations / service principals) where possible.
Avoid creating interactive “svc_” users unless there is a genuine need for an interactive sign-in. - Every service / workload identity has an owner, a purpose, and a review date.
If it can’t be explained, it doesn’t get to exist. - Service and workload identities are handled explicitly in policy scope.
Microsoft’s own risk policy guidance calls out service accounts and service principals as items you should deliberately consider when designing sign-in and risk policies.
For legacy applications and protocols, CalderCloud keeps the same discipline we introduced earlier.
- Block legacy authentication using Conditional Access, starting in Report-only mode to understand impact. Microsoft provides a specific “block legacy authentication” policy pattern for this.
- Where a legacy dependency is truly unavoidable, CalderCloud does design fixes (modern auth/OAuth support, alternative connectors, replacement apps) rather than permanent “ignore it” exceptions.
This is where “safe by default” becomes real: exceptions are designed, not improvised.
End Users / Curious Readers
You’ll be prompted to register sign-in methods once (combined registration), and then sign-ins become more consistent.
If you invite a guest to collaborate, they may be asked to complete MFA before they can access CalderCloud resources.
If you’re stuck, you may be issued a Temporary Access Pass (TAP) to get you safely back in and let you set up stronger methods.
IT Lead / Management
- You are approving a baseline that reduces “one stolen password = incident”, and a guest posture that avoids “anyone can wander in”.
- You are also signing off a governance principle: service / workload identities must be owned and reviewed, not created as anonymous shortcuts.
- Success looks like: fewer account compromise events, fewer frantic access problems, and auditable evidence that emergency accounts exist and are monitored.
Day 4 now has the identity “muscle” behind the earlier policy baseline: we’re not just saying “use Conditional Access”; we’re defining how people authenticate, how admins are hardened, how emergency recovery works, and how non-human identities don’t become a silent back door.
Here is a simple overview of the activities a Sysadmin can expect to be responsible for creating, deploying and managing:
- Enable and govern authentication methods
- Entra ID → Authentication methods → Policies (enable/target methods; manage policy).
- Enable Temporary Access Pass and scope it to appropriate groups.
- Make onboarding survivable
- Enable combined registration (MFA + SSPR).
- Turn on an MFA registration campaign to nudge users to complete setup.
- Enforce MFA through Conditional Access
- CA policy for staff: require MFA (or an authentication strength, where you’re ready).
- CA policy for guests / external users: include “All guest and external users” and require MFA.
- CA policy for admins: require phishing-resistant MFA via authentication strengths (where licensing and readiness allow).
- Build emergency access properly (two accounts, monitored, tested)
- Follow Microsoft’s emergency access account guidance: two or more accounts, strong methods (passkeys / certificates), alerting and regular validation drills.
- Kill legacy auth safely
- Create a “block legacy authentication” Conditional Access policy in Report-only first, then enforce in waves.
PowerShell Option for Automate Evidence, Onboarding and Drift checks
This is where PowerShell comes in – as discussed in an earlier post, this content is directed at Sysadmins that are familiar and understanding of PowerShell and its connectivity with a Microsoft 365 Tenant; specifically Microsoft Graph (the Microsoft Graph PowerShell Software Development Kit (SDK)), which talks to Microsoft Graph (Microsoft’s application programming interface (API) for Microsoft 365 and Entra ID).
Just as importantly, PowerShell supports CalderCloud’s “safe by default” account model: you can run read-only checks using least privilege, and you can automate reporting using non-user identities (service / workload accounts) rather than borrowing someone’s interactive admin session.
This section focuses on three practical admin outcomes:
- Export and evidence Conditional Access (CA) policies
- Inspect and (optionally) update the authentication methods policy (including Temporary Access Pass (TAP))
- Support onboarding/recovery by issuing a TAP safely for a user
Prerequisites (Graph connection)
# Install once
Install-Module Microsoft.Graph -Scope CurrentUser
# Connect (delegated) with least-privilege scopes for reporting + policy read
Connect-MgGraph -Scopes “Policy.Read.All”,”AuditLog.Read.All”
Microsoft documents Graph PowerShell authentication patterns (delegated and app-only).
Evidence pack: export Conditional Access policies (read-only)
Import-Module Microsoft.Graph.Identity.SignIns
# Export policy names + states for evidence
$ca = Get-MgIdentityConditionalAccessPolicy -All
$ca | Select-Object DisplayName, State, Id | Sort-Object DisplayName | Export-Csv “.\CA-Policies.csv” -NoTypeInformation -Encoding UTF8
# Export full JSON for audit / change tracking
$ca | ConvertTo-Json -Depth 50 | Out-File “.\CA-Policies.json” -Encoding UTF8
Get-MgIdentityConditionalAccessPolicy is the supported Graph PowerShell cmdlet for retrieving CA policies.
Inspect authentication methods policy (read-only)
This lets you evidence what methods are enabled/targeted in Entra ID without screenshots.
Import-Module Microsoft.Graph.Identity.SignIns
# Read overall authentication methods policy
$amp = Get-MgPolicyAuthenticationMethodPolicy
$amp | ConvertTo-Json -Depth 50 | Out-File “.\AuthenticationMethodsPolicy.json” -Encoding UTF8
Microsoft documents Get-MgPolicyAuthenticationMethodPolicy and the associated policy object.
To inspect individual method configurations (including TAP configuration as a method policy object):
# List method configurations (you’ll see IDs for each method config)
Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration -All | Select-Object Id, ‘@odata.type’ | Sort-Object ‘@odata.type’
The configuration cmdlet exists in the Identity.SignIns module.
Configure Temporary Access Pass by policy (optional, change-control)
If you want to manage Temporary Access Pass (TAP) configuration by code, Graph supports reading/updating the TAP method configuration. In Graph PowerShell you generally update authentication methods policy/configuration using Update-MgPolicyAuthenticationMethodPolicy or the configuration update cmdlets.
Important: do this in a dev tenant first. Keep Day 4 “create/change” portal-led unless you’re already comfortable with Graph SDK and PowerShell.
Issue a Temporary Access Pass for onboarding/recovery (practical win)
This is the real-world “Monday saver”: user can’t register MFA or lost their device, so you issue a Temporary Access Pass (TAP) as a controlled bridge.
Import-Module Microsoft.Graph.Identity.SignIns
# Requires appropriate permission (delegated or app) for user authentication methods operations
Connect-MgGraph -Scopes “UserAuthenticationMethod.ReadWrite.All”
$userId = “someone@caldercloud.co.uk”
# Create a TAP (example: 1 hour lifetime, single-use)
$tap = New-MgUserAuthenticationTemporaryAccessPassMethod -UserId $userId -BodyParameter @{
lifetimeInMinutes = 60
isUsableOnce = $true
}
$tap
Microsoft documents New-MgUserAuthenticationTemporaryAccessPassMethod as the Graph PowerShell method for creating a TAP on a user.
Optional: prompt users to register methods (registration enforcement)
If you want to “nudge” users to set up methods, Graph supports a registrationEnforcement property on the authentication methods policy (this is closely related to enforcing registration at sign-in time).
Whether you configure the “registration campaign” experience purely in the portal or also via Graph, the safe approach is the same: pilot first, measure impact, then expand.
External Collaboration Defaults: SharePoint, OneDrive and Teams (without turning “sharing” into “leaking”)
External collaboration is where “safe by default” either becomes real… or becomes a polite fiction. The same three words — share a file — can mean anything from “invite a known partner to a single document” to “accidentally create an anonymous link that lives forever”.
Tenant Foundations – Why we’re doing this now:
At this stage of the Tenant Foundations arc, CalderCloud is not actively using SharePoint, OneDrive, Teams, or any other collaboration workload in production. That’s deliberate. The goal here is to set the tenant-wide defaults and guardrails before adoption begins, so the first Teams, the first sites, and the first sharing links are born into a safe posture.
This is the “get it right now” phase: we configure the collaboration baseline while the tenant is quiet, predictable, and easy to reason about — rather than trying to unwind hundreds of sites, anonymous links, and guest permissions later when the business is already relying on them. In plain terms: it’s cheaper (and kinder) to design the rules before the game starts than to rewrite them mid-match.
So CalderCloud sets defaults that make the safe path the easy path, and makes the risky path an intentional, logged decision.
The four sharing levels: decide your maximum, then tighten by site
At tenant level, SharePoint and OneDrive sharing is set on a sliding scale (most restrictive → most permissive):
- Only people in your organisation
- Existing guests
- New and existing guests
- Anyone (anonymous links)
These are configured in the SharePoint admin centre → Policies → Sharing, and Microsoft explicitly calls out that you set an organisation-level baseline first.
Two details matter for Day 4:
- The organisation-level setting is the maximum openness. Individual sites can be set more restrictive, but not more permissive.
- Even if the tenant allows external sharing, not every new site allows it by default (Microsoft notes this behaviour).
CalderCloud stance (baseline):
- Prefer New and existing guests (authenticated guests) for most collaboration, and avoid Anyone (anonymous) links as a default posture.
- If anonymous links are ever allowed, they must be time-bound and treated as an exception rather than a convenience.
Default link types: make “specific people” the default, not “anyone with the link”
Sharing level is only half the story. The other half is what users see as the default link type when they hit Share.
Microsoft documents the default link types you can set, including Specific people (most restrictive) and notes you can set the default for the organisation and override per-site.
CalderCloud “safe by default” choice:
- Default link type = Specific people
- Default permission = View (where appropriate for broad collaboration; “Edit” becomes deliberate)
That single decision quietly reduces accidental oversharing because users have to name the person rather than relying on a link that can be forwarded.
Site-level tightening (for sensitive areas):
For sites like Finance, HR, or anything client-confidential, you explicitly tighten sharing at the site level. Microsoft’s site-level sharing guidance includes domain restriction options and makes it clear you can apply stricter controls per site.
The Teams nuance that catches people out:
Microsoft notes that to change the default link type for a Teams private or shared channel site, you must use Set-SPOSite (PowerShell), not just the portal.
Teams collaboration: external access vs guest access (two different beasts)
In Microsoft Teams (Teams), there are two main ways to collaborate with people outside your organisation:
- External access: chat/meet/call with people in other organisations while they stay in their tenant.
- Guest access: bring an external person into your tenant’s team, channels, files, and resources.
Microsoft provides a clear comparison and explains both models.
CalderCloud baseline choices:
- Guest access is enabled, because real project collaboration needs shared files and channels — but guest sign-in is protected by the identity baseline (Conditional Access + Multi-Factor Authentication (MFA)).
- External access is constrained, ideally using an allow-list of trusted partner domains for chat/meetings. Microsoft documents both the portal steps for domain allow/block control and the important nuance that blocked domains might still join meetings anonymously if anonymous meeting access is allowed.
This isn’t a negative paranoia on me or my way. It’s containment. Recent reporting has highlighted how external Teams interactions can be abused for phishing/malware delivery if organisations are too open by default — another reason CalderCloud prefers trusted-domain patterns and clear user education.
Portal-first, low-drama rollout
This is the “no drama” route for a new tenant where no real collaboration Teams or sites are live yet. You might see the default root SharePoint site and system sites, but you should not yet have any additional sites created – e.g., “Finance”, “HR”, “Client Alpha” or busy Teams in production.
All of the steps below should be done with dedicated admin accounts, not everyday user accounts, consistent with Day 4’s identity posture.
You won’t really feel these settings yet. The point is that when SharePoint, OneDrive and Teams go live later, they start safe by default, instead of inheriting “whatever the portal shipped with”.
Step 0 – Confirm you’re still in “Tenant Foundations” territory
- Go to SharePoint admin centre
- Microsoft 365 admin centre → Show all → SharePoint.
- Go to Active sites.
- In a “clean” Tenant Foundations state you’ll typically only see:
- the root site (https://<tenant>.sharepoint.com),
- the default “Communication” or “Team” site the tenant shipped with,
- a handful of service sites (app catalogue, MySite host, etc.).
- In a “clean” Tenant Foundations state you’ll typically only see:
If you already see Finance, HR, project or client sites with real data, treat them as a remediation mini-project, not part of this “day 4” baseline.
Step 1 – Set tenant-wide SharePoint / OneDrive sharing baseline
Goal: organisation-level defaults for external sharing and link behaviour that are sane for a small-but-serious organisation.
- In the SharePoint admin centre, go to Policies → Sharing.
- Under External sharing:
- SharePoint: set to New and existing guests.
- OneDrive: set to Same as SharePoint or more restrictive (never more open than SharePoint).
- Under File and folder links:
- Choose the type of link that’s selected by default → Specific people.
- Choose the permission that’s selected by default → View.
- Scroll down, review any “Anyone” link options and ensure they have short expiry (for example 30 days) if you allow them at all.
- Select Save.
At this point, if someone shares content later during the adoption topics, the safest option (specific people, view-only) will already be the default.
Step 2 – Design your future “sensitive sites” model (no real sites yet)
Because we’re still in Tenant Foundations, Finance, HR and key client sites don’t exist yet. Step 2 is about deciding how you’ll treat them and writing that into the charter, not about clicking around sites that don’t yet exist.
In your Baseline Charter, add a small “future sensitive sites” table:
Planned site | Example URL | Initial sharing stance | Notes |
Finance | https://<tenant>.sharepoint.com/sites/Finance | Existing guests only, specific-people links, View by default | Payroll, invoices, bank details. No broad external access. |
HR | https://<tenant>.sharepoint.com/sites/HR | No external sharing by default | Personnel records, contracts, performance data. |
Exec / Board | https://<tenant>.sharepoint.com/sites/ExecBoard | Existing guests only / specific-people, View | Board packs and strategy documents. |
Also document the site-level “how” for when those sites do exist:
- SharePoint admin centre → Active sites.
- Select the site → Sharing (in the command bar).
- For Finance/HR/Exec sites (once created):
- Set External sharing more restrictive than the tenant baseline (for example Existing guests only or Only people in your organisation).
- Override Default sharing link type and Default link permission if needed (always “Specific people”, “View” as the starting point).
Important: In Tenant Foundations you’re not expected to actually have these sites yet. The point is that future you doesn’t have to invent the rules under pressure.
Step 3 – Decide your starting Teams guest access stance
Teams guest access controls whether you can add external people as guests inside your teams (B2B). For CalderCloud’s tenant, the Day 4 baseline is:
- Guest access is On,
- capabilities are kept to a practical but conservative set,
- no Teams are in production yet, but the controls are ready.
Portal steps (you can run these now even if you’re not using Teams yet):
- Go to Teams admin centre
- Microsoft 365 admin centre → Show all → Teams.
- In the left nav, select Users → Guest access.
- Set Guest access to On.
- Under Messaging, a safe Day-4 baseline might be:
- Allow guests to edit and delete their own messages → On.
- Allow guests to delete sent messages → On.
- Allow guests to use chat → On.
- Under Meetings / Calling, you can start conservatively:
- Allow guests to make private calls → Off (channel conversations first, private calling later).
- Meeting join/participation options can be left at defaults initially and tightened in the collaboration topic.
- Select Save, then capture a screenshot into your “CollaborationEvidence” folder and you can add it to the baseline charter.
If your organisation is extremely risk-averse, you can leave Guest access Off for now, but record that choice and a “review by” date in the charter so it doesn’t become a forgotten default.
Step 4 – Teams external access (federated chat/meetings)
Teams external access controls chat and meetings with other Microsoft 365 organisations (federation), separate from guest access. Best practice for a fresh tenant is to start closed, then move to “allow only specific domains” once you know who you actually need to talk to.
For Day 4:
- Go to Microsoft Teams admin centre → Users → External access.
- Make sure you’re on the Organisation settings tab.
- Under “Manage external domains for this organization”, leave the toggle On – this lets you control federation with the dropdown below the toggle.
- In “Allow or block external domains”, use the dropdown and choose:
- Block all external domains
- In your baseline charter, add a small table of future trusted domains (partners/clients), for Example
Domain | Why it would be allowed |
partner1.co.uk | Main consulting partner |
partner2.com | Key SaaS vendor |
client-alpha.co.uk | Strategic client project work |
Note in the charter that before the first real external project, you’ll switch this to Allow only specific external domains and populate the allow-list with those domains.
This way, no cross-tenant chat is possible by default, which lines up with recent advice to avoid open federation until you deliberately choose trusted partners.
PowerShell Option – Baseline by code
This is where PowerShell comes in – as discussed in an earlier post, this content is directed at Sysadmins that are familiar and understanding of PowerShell and its connectivity with a Microsoft 365 Tenant; specifically Microsoft Graph (the Microsoft Graph PowerShell Software Development Kit (SDK)), which talks to Microsoft Graph (Microsoft’s application programming interface (API) for Microsoft 365 and Entra ID).
Just as importantly, PowerShell supports CalderCloud’s “safe by default” account model: you can run read-only checks using least privilege, and you can automate reporting using non-user identities (service / workload accounts) rather than borrowing someone’s interactive admin session.
SharePoint / OneDrive baseline
The Set-SPOTenant parameters we’re leaning on are:
- SharingCapability (Disabled / ExternalUserSharingOnly / ExternalUserAndGuestSharing / ExistingExternalUserSharingOnly)
- DefaultSharingLinkType and DefaultLinkPermission (for the default link experience)
- RequireAnonymousLinksExpireInDays (tenant-wide “Anyone link” expiry).
For Day 4 you might show something like:
# Connect to SharePoint Online admin service
Connect-SPOService -Url “https://<tenant>-admin.sharepoint.com”
# Capture current baseline (for your evidence pack)
Get-SPOTenant |
Select SharingCapability,
DefaultSharingLinkType,
DefaultLinkPermission,
RequireAnonymousLinksExpireInDays,
SharingDomainRestrictionMode,
SharingAllowedDomainList |
Format-List
# Apply a CalderCloud-style baseline
Set-SPOTenant `
-SharingCapability ExternalUserSharingOnly ` # New + existing guests, no Anyone links
-DefaultSharingLinkType Direct ` # “Specific people” as default link
-DefaultLinkPermission View ` # View by default
-RequireAnonymousLinksExpireInDays 7 ` # If Anyone links are enabled later
-SharingDomainRestrictionMode AllowList ` # Only allow named domains
-SharingAllowedDomainList “partner1.co.uk,partner2.com”
Pre-staged “harden these sites when they exist” script
The logic here uses Set-SPOSite to override sharing and default links for specific sites; Microsoft explicitly calls out that you must use PowerShell for certain Teams-connected sites’ defaults.
The important thing is to be honest that, in Day 4, this script will mostly log “site not found yet” – which is fine, it’s pre-staged:
$sensitiveSites = @(
“https://<tenent>.sharepoint.com/sites/Finance”,
“https://<tenant>.sharepoint.com/sites/HR”,
“https://<tenant>.sharepoint.com/sites/ExecBoard”
)
foreach ($url in $sensitiveSites) {
$site = Get-SPOSite -Identity $url -ErrorAction SilentlyContinue
if ($site) {
Write-Host “Hardening $url …”
Set-SPOSite -Identity $url `
-SharingCapability ExistingExternalUserSharingOnly `
-DefaultSharingLinkType Direct `
-DefaultLinkPermission View
}
else {
Write-Host “Site $url not found yet – this is expected in the Tenant Foundations arc.”
}
}
That keeps the baseline honest: no real sites yet, but the guard rails are ready.
Teams external access via PowerShell
The Teams federation cmdlet is Set-CsTenantFederationConfiguration; the critical bits today are:
- AllowFederatedUsers – if this is False, users can’t talk to any external domain, regardless of allow/block lists.
- AllowedDomainsAsAList – manages the allow-list when you’re in “allow specific domains” mode.
For Day 4’s “block everything” baseline you can mirror the portal UI steps like this:
Connect-MicrosoftTeams
# Capture current federation settings for your evidence pack
Get-CsTenantFederationConfiguration
# Enforce a full block on external Teams federation
Set-CsTenantFederationConfiguration -AllowFederatedUsers $false
Later, when CalderCloud intentionally moves to an “allow only specific external domains” posture, the script looks like:
# Example: future allow-list (not for Day 4)
$allowedDomains = @(“partner1.co.uk”, “partner2.com”, “client-alpha.co.uk”)
Set-CsTenantFederationConfiguration -AllowFederatedUsers $true -AllowedDomainsAsAList @{ Replace = $allowedDomains }
Core Auditing, Logging and Alerting: so we actually notice trouble
In the Tenant Foundations arc, CalderCloud isn’t trying to run a full incident-response programme yet; we’re making sure the tenant can tell the truth. That means:
- activity is being recorded (auditing/logging),
- it’s searchable and exportable (evidence),
- the right people can access it (permissions), and
- the “high value” warnings reach humans (alerting), without creating noise.
This is the difference between “we think it’s fine” and “we can prove it’s fine (or prove it’s not)”.
Microsoft Purview Audit and unified audit logging: enable, verify, prove
Microsoft Purview Audit (Microsoft Purview’s audit solution) relies on unified audit log being enabled. You don’t assume this is on; you have to verify it. Microsoft provides both portal guidance and the specific property to check
Portal verification (IT Lead / Management / Curious Reader):
- Go to the Microsoft Purview portal → Audit.
- If you’re prompted to start recording activity, enable it.
- Once enabled, allow time for ingestion and then run a small test search to confirm records appear.
PowerShell verification (Sysadmins / Tenant Admins only):
- Connect to Exchange Online PowerShell and run:
- Get-AdminAuditLogConfig | FL UnifiedAuditLogIngestionEnabled
- If it’s off, enable it via:
- Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
This is a foundational contract: if unified audit log isn’t on, your later “alerts”, “investigations”, and “evidence packs” are non-existent or worse, not relevant.
Permissions and separation of duties: who can search the audit log (and who should not)
Auditing is useless if the wrong people can’t access it – or if the wrong people can.
To search audit events in Microsoft Purview, Microsoft states users need roles such as Audit Logs or View-Only Audit Logs, and you can assign these through appropriate role groups/custom role groups.
CalderCloud’s “safe by default” approach here:
- End Users: do not get audit search access.
- IT Lead / Management: may get reports and summaries, not raw audit access.
- Sysadmins / Security admins: get the least privilege needed:
- “Audit Reader” style capability for investigation,
- tighter “Audit Manager” / role management only for a very small set of trusted admins,
- everything performed via named admin accounts, not everyday accounts.
This matters because audit logs can contain sensitive details about users, files, and access patterns. Giving broad access is its own security incident waiting to happen.
Mailbox auditing: validate what’s logged and how long it’s retained
Email compromise is still one of the most common “blast radius” events in Microsoft 365, so mailbox auditing must be understood early.
Microsoft’s mailbox auditing guidance explains retention defaults and how to adjust the audit log age limit using Exchange Online PowerShell (for example, Set-Mailbox -AuditLogAgeLimit).
Two practical points to keep straight:
- Mailbox activities are included in the wider Microsoft 365 audit log activity set.
- Mailbox audit log record retention has defaults (and can be changed), but retention and searchability can vary by capability/tier and by what you’re querying. Treat retention as a baseline decision you document, not a magical infinite history.
Tenant Foundations goal: confirm mailbox auditing is on and that CalderCloud can retrieve and export mailbox-related audit events when needed.
Alerting that a small team can sustain: Defender alert policies as “early smoke alarms”
CalderCloud needs alerts that are actionable. A “security team” drowning in noise is just a slow-motion incident.
Alert policies are in the Microsoft Defender portal and the exact navigation path is:
Microsoft Defender portal → Email & collaboration → Policies & rules → Alert policy.
For Day 4, CalderCloud keeps the baseline small and high-value. The point isn’t perfect coverage; it’s “catch the big, common bad stuff early”:
- Privilege changes: admin role assignment / unexpected privilege elevation.
- Suspicious mailbox behaviour: new forwarding, redirect, unusual inbox rules (common in account compromise).
- Malware/phishing detection signals: alerts that indicate messages were detected as malicious, especially if user impact is high.
- Burst activity markers: unusually high volume actions (downloads/sharing) once collaboration workloads go live — this becomes more meaningful later, but we set the foundations now so it’s easy to tighten later.
We’re not trying to guess every future scenario; we’re giving CalderCloud a minimal set of smoke alarms that doesn’t require a 24/7 team to interpret.
SOC/SIEM hand-off: how audit and threat signals leave the tenant
CalderCloud has a central Security Operations Centre (SOC) and may feed into a Security Information and Event Management (SIEM) platform. The Day 4 baseline must make that hand-off possible and predictable.
The recommended route for programmatic, SIEM-friendly audit retrieval is the Office 365 Management Activity API (Application Programming Interface), and Microsoft explicitly recommends it for programmatic download use-cases rather than relying on Search-UnifiedAuditLog in scripts.
Tenant Foundations goal: document the path CalderCloud will use and who owns the path (tenant admins vs SOC).
Portal-first, Step-by-Step guide
Step 1 – Confirm unified audit log ingestion is enabled
- Microsoft Purview portal → Audit → enable recording if prompted.
- Assign least-privilege audit roles (Audit Logs / View-Only Audit Logs style access) via Purview role groups.
- Validate by running a simple audit search and confirming records return.
Step 2 – Verify mailbox auditing posture
- Confirm mailbox audit events are being captured and can be found in audit searches.
- Document retention expectations and decide whether AuditLogAgeLimit needs adjustment (and why).
Step 3 – Create a minimal baseline set of alert policies in Microsoft Defender
- Microsoft Defender portal → Email & collaboration → Policies & rules → Alert policy.
- Create 3–5 baseline policies only (privilege change + suspicious mailbox behaviour + high-severity email detections).
- Route alerts to the right place (SOC queue vs tenant admin queue), and document ownership.
Step 4 – Document SOC/SIEM hand-off
- Decide whether the SOC will consume audit via the Office 365 Management Activity API (recommended for programmatic download and SIEM ingestion).
- If using Sentinel, enable the Defender XDR connector for incidents/alerts sync.
- Document: what’s collected, who watches it, and what triggers escalation.
PowerShell Option – Repeatable checks
This is where PowerShell comes in – as discussed in an earlier post, this content is directed at Sysadmins that are familiar and understanding of PowerShell and its connectivity with a Microsoft 365 Tenant; specifically Microsoft Graph (the Microsoft Graph PowerShell Software Development Kit (SDK)), which talks to Microsoft Graph (Microsoft’s application programming interface (API) for Microsoft 365 and Entra ID).
Just as importantly, PowerShell supports CalderCloud’s “safe by default” account model: you can run read-only checks using least privilege, and you can automate reporting using non-user identities (service / workload accounts) rather than borrowing someone’s interactive admin session.
Verify and enable unified audit ingestion
# Exchange Online PowerShell (named admin account)
Connect-ExchangeOnline
# Check if unified audit log ingestion is enabled
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
Microsoft documents UnifiedAuditLogIngestionEnabled and managing it with Set-AdminAuditLogConfig.
# Enable unified audit log ingestion (if required)
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true
# Re-check after a short period
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled
Pull audit records for a time window (ad hoc investigation / evidence)
# Search the unified audit log for the last 24 hours
$start = (Get-Date).AddHours(-24)
$end = (Get-Date)
Search-UnifiedAuditLog -StartDate $start -EndDate $end -SessionCommand ReturnLargeSet | Export-Csv “.\UnifiedAuditLog-Last24Hours.csv” -NoTypeInformation -Encoding UTF8
Microsoft documents Search-UnifiedAuditLog usage and notes that for programmatic download at scale you should prefer the Microsoft 365 Management Activity API.
Targeted search patterns (useful in the real world)
# Exchange admin activity (useful when validating changes)
$start = (Get-Date).AddHours(-24)
$end = (Get-Date)
Search-UnifiedAuditLog -StartDate $start -EndDate $end -RecordType ExchangeAdmin -SessionCommand ReturnLargeSet | Export-Csv “.\ExchangeAdminAudit-Last24Hours.csv” -NoTypeInformation -Encoding UTF8
Microsoft notes Exchange admin audit events may take time to appear (plan for delay when validating).
Where Day 4 Leaves CalderCloud – and What Happens Next
Day 4 is the point in Tenant Foundations where CalderCloud stops talking about “doing security properly one day” and actually sets a floor:
- sign-ins are protected by design,
- sharing starts from safe defaults,
- activity is logged and can be explained,
- and all of that is written down, not just remembered.
From here on, “safe by default” isn’t a slogan – it’s a set of documented and approved settings that any future admin can pick up without guesswork.
What should exist now (concrete outputs)
By the end of Day 4, CalderCloud should be able to point to real agreed decisions, not just good intentions:
- Identity baseline in Entra ID
- Security Defaults: decision made and recorded (kept or replaced).
- Conditional Access baseline: small, named policies in place, tested in Report-only mode and then enforced in stages.
- Multi-Factor Authentication (MFA): onboarding journey defined (combined registration, Temporary Access Pass for recovery).
- Admin and break-glass accounts: separate named admin accounts in use, emergency accounts created, excluded from Conditional Access, monitored and tested.
- Service/workload identities: owned, documented and treated as first-class citizens in the design (no mystery “svc_” users hanging around with unlimited rights).
- Collaboration baseline (set before real usage)
- Tenant-wide external sharing posture: chosen and written down (for example, “New and existing guests” rather than “Anyone”).
- Default link behaviour: link type and default permission set to safer options (for example, “Specific people” and “View” as default).
- Sensitive sites: initial high-risk areas (Finance, HR, client-critical) identified and tightened at site level.
- Teams external and guest access: deliberately configured, not left on “whatever the defaults were”.
- Audit and alerting baseline
- Unified audit logging: enabled, checked using PowerShell, and proven with a small test export.
- Mailbox auditing: behaviour confirmed and expectations about how long you can look back documented.
- Alert policies: a short list of high-value alerts (privilege changes, mailbox forwarding/rules, high-impact detections), routed to the right place (tenant admins and/or Security Operations Centre (SOC)).
- SOC / Security Information and Event Management (SIEM) path: agreed route for sending signals (for example Office 365 Management Activity API and/or Microsoft Sentinel with the Defender XDR connector), written into the runbook.
- Charter, evidence reports and review governance
- Baseline charter: one document that lists settings, current values, owners, and “why this is set like this”.
- Evidence reports:
- IdentityEvidence – Conditional Access and authentication review exports + Temporary Access Pass monitored access control;
- CollaborationEvidence – SharePoint/OneDrive and key site exports;
- AuditEvidence – audit configuration and sample log exports + alert policy list.
- Exceptions register: any deviations from the baseline documented with owner, reason, risk and expiry date.
- Weekly/monthly/quarterly review pattern written down and scheduled, so the baseline doesn’t quietly decay.
If those four blocks exist, CalderCloud has a Tenant Foundations baseline it can trust.
Sources and last verified
The Day 4 guidance on “safe by default” security and sharing settings was last reviewed against the following sources:
Identity, MFA and baseline security
Microsoft Learn – Configure Security Defaults for Microsoft Entra ID.
Microsoft Learn – Microsoft Entra Conditional Access: Zero Trust policy engine.
Microsoft Learn – Set up multifactor authentication for Microsoft 365.
Microsoft Learn – Microsoft 365 for business security best practices.
Sharing and collaboration controls
Microsoft Learn – Overview of external sharing in SharePoint and OneDrive.
Microsoft Learn – Manage sharing settings for SharePoint and OneDrive in Microsoft 365.
Audit, logging and alerting
Microsoft Learn – Search the audit log in the Microsoft Purview portal and Get started with auditing solutions in Microsoft Purview.
Microsoft Learn – Alert policies in the Microsoft Defender portal and related Defender XDR alert documentation.
Last verified
Last verified against the sources above: 21 December 2025.
Your next step (within the next few working days)
To stop Day 4 becoming “we’ll finish that later”, there are three simple actions to lock in now:
- Run and file the evidence scripts once, on purpose
- Run the identity, collaboration and audit PowerShell commands from Day 4.
- Save the outputs into the three evidence folders alongside the charter, with today’s date in the filenames.
- Note in the charter which scripts you used and where they live.
- Fill in the missing cells in the charter tables
- For each pillar (Identity, Collaboration, Audit & Alerting), complete the “owner”, “last checked” and “why this value?” columns.
- Populate the Exceptions table with any “temporary” configurations you know about now, so they don’t disappear into folklore.
- Put the review rhythm into real calendars
- Create a short recurring weekly slot for hygiene checks.
- Create a monthly review meeting for IT Lead(s), Managers, Sysadmins and Tenant Admins together to look at drift and exceptions.
- Schedule a quarterly resilience / disaster recovery drill (break-glass test + audit search test), linked directly to the charter.
Once those three things are done, Day 4 is no longer “a blog post you liked” – it’s how your tenant is actually run.
Safety note (who should be doing what)
Everything in Day 4 – assumes:
- changes are made using named admin accounts,
- everyday user accounts are not granted broad admin roles (especially not Global Administrator) just to “get something done quickly”, and
- PowerShell is used from appropriately privileged sessions, not from personal day-to-day identities.
If your reality looks different, the first corrective action is not “run more scripts”. It’s to fix the account identity model so the rest of this baseline isn’t built on sand.
Coming Next:
Day 5 – Tenant Branding, Help & User-Facing Touchpoints
Tenant Foundation Review / Summary
And onwards into an new Modern Workplace Master series arc – identity and devices
🧭 Follow the full journey: You’re welcome to follow along quietly, Questions, disagreements and “we tried this and it hurt” stories are all part of the point. You can catch each post right here and can follow along on LinkedIn, Instagram, or Bluesky.
Thank you for joining me on this journey.
🔗 SharePointMark – Modern Workplace Mastery
#ModernWorkplace #ModernWorkplaceMastery #MentalHealthAtWork