120 Licences, Nine Countries, No Office: Managing Microsoft 365 for a Remote Team

When there is no office, the tenant is the company. The real risk in a fully remote Microsoft 365 environment is rarely a security failure — it is drift: licences nobody remembers assigning, leavers who keep access, and renewals nobody owns. Fixing that is licence hygiene on a schedule, not a security programme.

A fully remote team, one Microsoft 365 tenant, no office

Picture a software company of around 120 people. There is no headquarters in the usual sense — engineering is split across a few cities in Asia, customer success sits mostly in the Gulf, a small product and design group works from Europe, and sales covers Australia and the rest of Asia-Pacific from wherever the person happens to live. Everyone was hired remote. Nobody has ever walked into an office and been handed a laptop by an IT person standing in front of them. This is a composite picture, not a named client, but the shape of it is ordinary for a modern remote-first software or services business.

For a company like this, Microsoft 365 is not an add-on to the office network. It is the office. Email, chat, files, calendars, video calls, the identity that every other SaaS tool logs in through — nearly all of it sits inside one Microsoft 365 tenant. There is no server room to secure, no badge system to audit, no physical perimeter at all. The tenant is the perimeter, and it is also the filing cabinet, the phone system and the front door.

The head of operations or chief of staff who ends up owning this problem usually did not sign up to run IT. They inherited a Microsoft 365 admin account because somebody had to have it, and the actual day-to-day administration has been handled in whatever spare time existed between hiring, payroll and the rest of the job. That is the starting point this article is written for.

Why "we are not looking for a security programme" is a reasonable place to start

It is worth saying plainly: a 120-person remote company that says it does not want an elaborate security programme is not being careless. For a business at this size, without regulated data, without a compliance mandate forcing a specific control framework, a full security operations build-out — a security operations centre, a dedicated analyst team, formal audits against a named standard — is usually the wrong amount of investment for the actual risk in front of it. Buying more security than the business needs is still a cost, and it is a cost that does not fix the problem that is actually causing trouble day to day.

The trouble that is actually causing problems in a tenant like this is rarely a sophisticated attack. It is administrative drift: an account that should have been disabled six months ago, a licence tier bought for a role that no longer exists, a renewal that quietly went through on a plan nobody re-evaluated. None of that requires a security programme to fix. It requires someone who owns the tenant the way an office manager owns a building — not glamorous, not framed as security, but done on a schedule.

That distinction matters for the rest of this article. Nothing here asks a 120-person remote company to build a security function it does not need. It asks for the small number of things that are genuinely non-negotiable regardless of size, and for ordinary licence and access hygiene to be treated as operational work rather than left to whoever has a spare hour.

What actually goes wrong in a distributed Microsoft 365 tenant?

Four patterns show up again and again in tenants that have grown without a single person clearly responsible for them. None of the four is dramatic on its own. Together, over a year or two, they add up to a tenant that costs more than it should and controls less than anyone assumes it does.

Orphaned licences nobody remembers assigning

A contractor finishes a project and their account is never disabled. A role is restructured and the old licence stays assigned to an account nobody uses. A pilot subscription for a team tool gets ten seats provisioned and only three are ever touched. None of this is deliberate waste — it is simply what happens when licence assignment is a one-way action that nobody revisits. In a distributed team, there is no equivalent of an office manager noticing an empty desk, so orphaned licences tend to survive far longer than they would where people can see each other's chairs.

Leavers who keep access longer than anyone intended

In a company with an office, offboarding has a physical prompt: the laptop comes back, the badge is deactivated, someone notices the empty chair. In a fully remote company, the only prompt is whoever remembers to tell IT. If the person leaving is in a time zone eight hours removed from whoever administers the tenant, "remembers to tell IT today" can easily become "gets told about it three days later" — and for those three days, a departed employee's mailbox, files and any connected SaaS tool are still exactly as accessible as they were the day before.

Licence tiers that don't match the work people actually do

Licence tiers accumulate history. Someone was given a premium tier two years ago for a project that has since ended. A new hire is given whatever tier the previous person in that role had, whether or not it matches what the new hire actually does. Multiplied across 120 people over a few years, a tenant typically ends up with a handful of expensive licences on people who need the basic tier, and occasionally the reverse — someone doing work that genuinely needs a higher tier, still on the entry-level one, quietly working around a limitation nobody has noticed.

Renewals nobody owns

Microsoft 365 subscriptions renew whether or not anyone reviews them first. Without a fixed point in the calendar where someone is responsible for asking "does this still match who we are and what we do," a renewal simply repeats last year's assignment. That is fine in a stable year. Over several years of hiring, restructuring and departures, it means the renewal date stops reflecting the company and starts reflecting whatever accumulated in the tenant since the last time anybody looked.

Why are joiners, movers and leavers a process, not a checklist?

A checklist assumes someone remembers to run it. That assumption is exactly what breaks down in a distributed team, because the person who should run the checklist for a leaver in one time zone is often asleep, or several time zones away, or simply not the person who found out first. A process, as distinct from a checklist, has three things a checklist usually does not: a single trigger that starts it regardless of who noticed first, a defined owner who is responsible for completing it even when the person leaving is in a time zone nobody else is awake in, and a record that shows whether it actually happened.

Joiners are the easier half. A new hire needs an account, the right licence tier for their role from day one, and access to the specific tools their team uses — not a blanket copy of the most senior person's access, which is how over-provisioned accounts get created in the first place. Movers are the half most companies forget entirely: someone who changes role internally rarely gets their old access reviewed, so a person who has moved through three roles in two years can end up holding the accumulated access of all three.

Leavers are where the time-zone problem bites hardest. The trigger for offboarding should not depend on which time zone the departing person's manager happens to be in. It should be triggered the moment HR confirms a departure date, run by a defined owner regardless of what time it is where that owner sits, and completed against a standard sequence — disable sign-in immediately, decide what happens to the mailbox and files, remove the licence once that is settled, and confirm the account no longer appears in any active list. Converting a departing employee's mailbox to a shared mailbox is Microsoft's own documented approach to this exact situation: the account stays in place as an anchor so the mail and files remain accessible to a manager or successor, sign-in is disabled, and the paid licence on that account can then be removed, which is what stops you paying for a seat nobody is using. A distributed team that treats this as a process — not a checklist someone might get to — is the difference between a leaver's access ending within hours and a leaver's access quietly persisting for as long as it takes someone to notice.

What should you measure for licence right-sizing, and how often?

Licence right-sizing does not require a security audit. It requires two habits: measuring who is actually using what, and doing it on a fixed schedule rather than whenever someone has time.

The two reports worth running every month

The first is a licence usage view. The Microsoft 365 admin centre's usage reports show, per application, which licensed users are actually active — a straightforward way to see a licence that has not been touched in months sitting against a name that may no longer even be the right name. The second is a sign-in activity view. In the Microsoft Entra admin centre, adding the last interactive and last non-interactive sign-in columns to the user list and sorting by date surfaces accounts that have gone quiet, which is often the first sign of a leaver whose offboarding did not fully complete, or a contractor account nobody remembered to time-box.

Run both once a month, assign one person to own the review, and treat every flagged account as a question rather than an automatic removal — some quiet accounts belong to someone on parental leave, not someone who left. That single habit, repeated monthly, catches most of the drift described above long before it becomes a renewal-time surprise.

What security is not optional, even for this buyer?

None of the following turns a 120-person remote company into a company running a security programme. It is the small, genuinely non-negotiable set that any tenant holding a company's entire operational life needs, regardless of appetite for anything larger.

Multi-factor authentication on every account is the first item, without exception, including contractor and shared-service accounts that are sometimes quietly excluded because they are inconvenient to enrol. Basic conditional access is the second: at minimum, requiring a managed or compliant device for access to the most sensitive systems, and treating a sign-in from an unexpected location or an unfamiliar device as something worth a second check rather than something that is waved through. Neither of these requires a security team to run — both are configuration decisions made once and then left running.

Why Microsoft's own retention is not a backup

The third item is a recoverable backup of what is actually in the tenant, and this is the point most often misunderstood. Microsoft's built-in retention, version history and recycle-bin mechanisms exist to protect against short-term accidental deletion inside the normal course of using the product — someone deletes a file and needs it back the same week, or a mailbox item is removed and needs restoring shortly afterwards. They are not designed, tested or operated as a backup in the sense a business continuity plan means it: a separate, monitored copy of the data with its own recovery point, restorable on a schedule you control rather than one Microsoft's retention settings happen to allow. Brocent's own cloud managed backup service exists specifically because of that gap — it sets up backup and recovery policies against defined recovery time and recovery point objectives, runs the backup jobs under continuous monitoring rather than leaving them to run unwatched, and includes periodic recovery drills that actually test whether a restore works, rather than assuming it would. For a fully remote company with no on-site IT to notice a failed backup job, a monitored, tested backup is closer to non-negotiable than optional — not because the tenant is under unusual threat, but because there is no other safety net if something does go wrong.

How do you manage devices when there is no office?

A remote company still has to answer the questions an office normally answers implicitly: is this device enrolled and known, does it meet a minimum security baseline, and what happens to it when someone leaves. Device enrolment should happen before a device is ever used for work, not retrofitted after the fact — a new hire's laptop, whether company-issued or personal, should be enrolled into device management as part of the same process that provisions their Microsoft 365 account, not as a separate step that depends on someone remembering.

A sensible baseline is short and enforceable: disk encryption turned on, the operating system kept current, and a way to remotely wipe corporate data if the device is lost or the relationship ends — none of which requires treating every laptop as a security incident waiting to happen. Personal devices used for work need a different answer than company-issued ones, because a full wipe of a personal phone is not something most companies want to do or most employees want done to them. The practical middle ground is separating corporate data into a managed space on the device, so it can be removed without touching personal photos or messages — the same approach we set out in detail in our guide to MDM and BYOD device management for a Singapore SaaS company, which covers the mechanics of that separation for a similarly distributed team, including how MDM and BYOD management handles the enrolment and containerisation itself. This article does not repeat that ground; if devices are the part of this that concerns you most, that is the piece to read next.

What multi-country wrinkles catch a distributed team off guard?

Beyond licences and devices, a handful of problems only show up because the team is spread across countries rather than sitting in one building, and they are easy to miss until they cause a specific incident.

Data residency expectations are the first. Different countries and different customers have different expectations about where data physically sits, and a fully remote team with staff logging in from a dozen countries needs to know, at minimum, where its Microsoft 365 data resides and whether that satisfies any commitment already made to a customer or regulator — a question worth answering before a customer asks it, not after.

Local holidays in support coverage are the second, and they are more disruptive than they sound. A support rota built around one region's calendar quietly has gaps on every other region's public holidays, and in a team spread across Asia, the Gulf, Europe and Australia, there is no single calendar that covers everyone. The fix is not more headcount; it is simply building the coverage plan against every relevant country's calendar from the start, rather than discovering the gap on the day it matters.

Payroll-driven start and end dates are the third, and the most common cause of the joiner-mover-leaver problems described earlier. HR and payroll systems, particularly across multiple countries with different employment law and different payroll cycles, do not always notify IT the moment a start or end date is confirmed — sometimes because the systems are not integrated, sometimes because nobody defined whose job it is to make the connection. A start date that reaches IT late means a new hire's first days are unproductive. An end date that reaches IT late is the leaver problem from earlier in this article, in its most common real-world form: not malice, not oversight of a checklist, but two systems that were never told to talk to each other.

Why does this belong inside one managed plan rather than four tools?

The four problems above — orphaned licences, leaver access, mismatched tiers, unowned renewals — plus the process gaps in joiner-mover-leaver handling and the multi-country wrinkles, all live in the same place: the Microsoft 365 tenant and the people and device records connected to it. That is the practical argument for managing them as one thing rather than as four separate purchases from four separate vendors.

Three ways a distributed team ends up managing Microsoft 365

• Nobody owns it, formally. Whoever set up the tenant originally still has admin rights, licence assignment happens ad hoc when someone asks, and offboarding depends on someone remembering to mention it. This is the default a fast-growing remote company falls into, not a decision anyone made on purpose, and it is where every problem described above comes from.
• A quarterly spreadsheet exercise. Someone exports a user list once a quarter, manually compares it against a headcount sheet, and cleans up what they find. This catches the worst of it eventually, but a leaver's access sits open for up to three months before the next review, and the exercise depends entirely on whoever is doing it having the time that quarter.
• One managed plan, run continuously. Licence usage and sign-in activity are reviewed monthly as a matter of routine rather than an occasional project, joiner-mover-leaver requests go through a single defined process regardless of time zone, and the same team that manages the tenant also manages device enrolment and the backup that protects it — because these are not actually four different problems, they are four views of the same tenant.

This is also where a claim worth being specific about applies. Brocent's own managed IT platform is built as a single engine rather than a stack of separate third-party tools stitched together — and because the platform's own modules share data, our managed IT service is built to flag unused, prepaid software seats and track hardware lifecycle as a normal function of the platform, rather than as a separate audit project someone has to remember to schedule. That is a real, current feature of how the platform works, not a hypothetical benefit — it is the same mechanism a spreadsheet exercise is trying to approximate manually, running continuously instead of once a quarter. The same platform coordinates the cloud services a Microsoft 365 tenant depends on and the device management layer described above, which is the practical version of "one engine, not four tools" rather than a slogan.

Frequently asked questions

Do we need an IT team for 120 remote staff?

Not necessarily a full internal team. What you need is someone — internal or outsourced — with clear, continuous ownership of the tenant: licence assignment, the monthly usage and sign-in review, and the joiner-mover-leaver process. A 120-person company can run this well with a managed IT provider handling the operational layer and an internal owner making the judgement calls a provider should not make alone, such as who genuinely needs a higher licence tier.

How do we find unused licences?

Run the Microsoft 365 admin centre's usage reports to see which licensed users are actually active in each application, and cross-check the result against a current headcount list, not the list from when the tenant was first set up. Anything licensed but inactive for an extended period is worth a direct question to that person's manager before removal, since some inactivity is legitimate — leave, a role change, a tool the person genuinely does not need day to day.

What happens to a leaver's mailbox and files?

The standard approach is to convert the departing employee's mailbox to a shared mailbox rather than deleting it, which keeps mail and files accessible to a manager or successor while disabling the person's ability to sign in. Once that conversion is done, the paid licence on the account can be removed, which is what actually stops the cost — deleting the account outright, before deciding what should happen to its contents, is usually the wrong first step.

Do we need Intune?

You need a mobile device management platform of some kind if the company issues devices or allows personal devices to access corporate data, and Microsoft Intune is the natural choice for a Microsoft 365-centric company because it is part of the same ecosystem. Whether you need it depends less on company size and more on whether devices currently have any enrolment or baseline at all — a company with zero device management today has a bigger gap to close than the choice of platform.

Is Microsoft's own backup enough?

Microsoft's built-in retention and recycle-bin features are designed for short-term accidental deletion, not for a tested, monitored backup with its own recovery point objective and a schedule of recovery drills. For a fully remote company with no on-site IT to catch a silent backup failure, a separate managed backup service — like Brocent's cloud managed backup — closes that gap without requiring anything close to a full security programme.

Which licence tier do we need?

This depends on what each role actually does, not on what the previous person in that role happened to have, and Microsoft's own published tiers and current pricing should always be checked directly at the point of decision, since they change. The monthly usage report described above is the right starting point for this question at renewal time, because it shows what each tier is actually being used for today rather than what it was bought for originally.

How is this priced?

Brocent's per-user managed IT plans are priced per employee per month, which is the natural fit for a problem that is fundamentally shaped per person — licences, access and devices all attach to an individual, not to a site or a server count. Current tier pricing and what each tier includes is on our pricing page.

Can you manage a tenant you did not build?

Yes — this is the normal starting point, not an exception. A tenant that has grown for two or three years without a single clear owner is exactly the situation a managed IT provider is set up to take over: the first step is the same usage and sign-in review described above, run once as a baseline assessment rather than a monthly habit, which typically surfaces most of the orphaned licences and stale accounts in the first pass.

From licence hygiene to a predictable per-user bill

None of what this article describes is a security programme, and none of it should be sold to you as one. It is ordinary operational hygiene for a company whose office happens to be a Microsoft 365 tenant instead of a building: licences that match the people who hold them, leavers whose access ends within hours rather than weeks, a small non-negotiable security baseline, devices that are known rather than assumed, and a monthly habit that catches drift before a renewal date turns it into a surprise. None of it is specific to any migration event, and if a migration is actually what you are facing, it is a different project with different steps, not this one — see our Microsoft 365 migration checklist if you are moving providers or planning a first move to Microsoft 365, or talk to us directly if you are consolidating tenants after an acquisition.

The reason this fits naturally under one monthly plan rather than a pile of point tools is that the problem itself is shaped per person, and Brocent's managed IT plan is priced the same way — per user, per month, so a 120-person distributed team pays for 120 people rather than for a stack of separately licensed tools that each solve one piece of this on its own. If you want a second opinion on your current tenant before you decide anything, talk to our team — we will tell you what we would look at first, and whether a full managed plan is actually the right size for what you have today.