Privileged Access Management for Australian Businesses: Controlling Admin Access Before It Controls You

There is a particular kind of worry that sets in the moment a business owner realises they have handed out the keys to everything and have no reliable way to know who used them, when, or why. For most Australian SMBs, that moment arrives when they start thinking seriously about cybersecurity — and discover that their IT provider, their internal IT person, and possibly a handful of staff all have full administrator access to every system in the business.

Privileged access management, or PAM, is the discipline of controlling exactly that. It defines who can access your most powerful accounts, under what conditions, for how long, and with what level of accountability. It is not an exotic enterprise concept. It is one of the most practical steps an Australian SMB can take to reduce their exposure to the attacks that cause the most damage.

This guide explains what privileged access is, why it is the primary target for attackers, what most small businesses are getting wrong right now, and what you can do about it — including with the Microsoft 365 tools you likely already pay for.

What Is Privileged Access?

A privileged account is any account that holds elevated permissions — the ability to do things that a standard user cannot. Where a standard user can open files, send emails, and run approved applications, a privileged account can do far more consequential things.

Examples of privileged access in a typical Australian SMB environment include:

• Windows local administrator accounts — accounts that can install and uninstall software, change system settings, and access all files on a local machine
• Domain administrator accounts — accounts that can manage the entire Windows domain, including creating and deleting user accounts, modifying Group Policy, and accessing every device and file share on the network
• Microsoft 365 Global Administrator accounts — accounts that have unrestricted access to the entire Microsoft 365 tenancy, including all email, SharePoint data, user accounts, security settings, and billing
• Cloud platform root or admin accounts — such as the AWS root account or Azure owner role, which can provision, delete, or modify any resource in the environment
• Database administrator accounts — accounts that can read, modify, or delete every record in every database the business operates
• Network device management accounts — the admin credentials used to manage firewalls, managed switches, and wireless controllers

These accounts are the keys to everything in your environment. Whoever controls them controls your business's data, systems, and communications. That is precisely why they are the most valuable target for any attacker who gets a foothold in your network.

Why Privileged Accounts Are Attackers' Primary Target

When an attacker compromises a standard user account — typically through a phishing email or a credential stuffing attack — they gain access to that user's world. They can read the person's emails, access the files they have permissions to, and potentially move laterally to other systems using the same credentials. That is damaging. But it is contained.

When an attacker compromises an administrator account, the situation changes entirely. They now have access to everything. They can read every user's email. They can access every file share and SharePoint library. They can create new accounts to establish persistence — accounts that remain even after the original breach is detected and the compromised admin account is disabled. They can disable or uninstall endpoint security tools. They can exfiltrate data at scale. And they can deploy ransomware across the entire environment.

This is why virtually every sophisticated cyber attack follows the same pattern. The attacker gains an initial foothold — often via a phishing email that tricks an employee into entering credentials on a fake login page. Then begins the dwell period: the attacker quietly explores the network, looking for ways to escalate their privileges. This process, called privilege escalation, is the critical phase. The attacker is hunting for credentials to a more powerful account.

They might find an unattended admin session on a shared workstation. They might discover a local administrator account that shares a password with the domain admin account. They might exploit a misconfigured service account. They might use a tool like Mimikatz to extract password hashes from memory on a Windows machine. The method varies, but the goal is the same: get from a standard account to a privileged account.

The Australian Cyber Security Centre (ACSC) has consistently identified admin account compromise as a feature of the most damaging Australian cyber incidents. The 2023–24 ASD Cyber Threat Report documented that compromised credentials — particularly those with elevated privileges — remain the most common initial access vector for serious intrusions affecting Australian businesses.

The Essential Eight — the ACSC's framework of core mitigation strategies — specifically includes "Restrict Administrative Privileges" as one of the eight foundational controls. This is not a nice-to-have. It is one of the eight controls assessed to provide the greatest risk reduction across the most common attack vectors.

The Most Common Privileged Access Mistakes

Most Australian SMBs have not thought systematically about who holds admin rights or how those rights are managed. The result is a predictable set of problems.

Everyone is an admin. When IT sets up a new workstation, the path of least resistance is to give the user local administrator rights. It means fewer support calls when users need to install software or change settings. But it also means that when a user opens a malicious email attachment, the malware runs with administrator privileges on their machine — giving it the ability to install itself persistently, disable security tools, and access far more data than it would otherwise be able to touch.

Shared admin credentials. Many businesses operate with a single domain admin password that is known to multiple people — the internal IT person, the MSP, sometimes a senior employee who asked for it once years ago. There is no audit trail. When something goes wrong, there is no way to know which person or which session was responsible. The password cannot be changed without coordinating with everyone who knows it, so it rarely changes. And if one of those people leaves the business on bad terms, the password must be changed immediately — something that is often overlooked in the chaos of an employee departure.

Standing privileges. An IT administrator who holds Global Admin access in Microsoft 365 has that access at 3am on a Sunday when they are not working, during their annual leave, and after they have stopped thinking about the task they originally needed it for. That permanent, always-on elevated access is called a standing privilege. It creates unnecessary exposure for the entire duration of the administrator's tenure — not just the moments they are actively performing admin tasks.

MSP admin accounts with no MFA. Managed IT providers often have administrative access to their clients' environments via accounts that were set up years ago, are shared between multiple technicians, and are not protected by multi-factor authentication. This is one of the most dangerous configurations in the Australian SMB landscape. An attacker who compromises an MSP's admin credentials may gain simultaneous access to dozens of client environments.

Forgotten service accounts. Service accounts are created to allow software integrations to function. An HR platform needs to read from Active Directory. A backup solution needs admin rights to access all files. A monitoring tool needs elevated permissions to report on system health. These accounts are often created by someone who is no longer at the business, documented nowhere, and never reviewed. They accumulate over years and many of them retain admin rights long after the software they were created for has been replaced.

The Principle of Least Privilege

The principle of least privilege is foundational to secure system design: every user, service, and system should have access only to what they need to perform their specific function — no more, and no less.

A finance team member does not need administrator rights to a file server. An HR platform integration does not need domain admin access to synchronise user data. A developer working on a test environment does not need production database credentials. When least privilege is applied consistently, the damage any single compromised account can do is bounded by exactly what that account needed to do its legitimate job.

For IT administrators, least privilege means maintaining two separate accounts: a standard user account for day-to-day work — reading email, attending meetings, using productivity applications — and a separate, dedicated admin account used only when performing specific administrative tasks. The admin account should never be the primary email account. It should not have a mailbox. It should exist for one purpose.

This separation matters because most malware and phishing attacks target the interactive user session. An administrator who reads their email in a standard user account and only elevates to their admin account for specific tasks dramatically reduces their exposure. If the standard account is compromised, the attacker gets access to a user with no special privileges.

Practical application starts with an audit. List every account in your environment that holds administrative rights of any kind. For each account, ask: what does this account actually need to do its function? Strip everything that does not directly serve that function. This is uncomfortable because it may create short-term friction. It is also one of the most effective things you can do.

Least privilege sits at the core of zero trust networking principles — the idea that no user, device, or account should be implicitly trusted, and that access should be continuously validated rather than assumed.

Just-in-Time Access — The Modern Approach

The logical extension of least privilege is just-in-time (JIT) access. Rather than granting permanent, always-on elevated permissions — standing privileges — JIT access provides elevation on request, for a defined period, for a specific stated purpose. When the time window expires, the elevated access is automatically revoked. No manual cleanup required. No risk of forgetting to remove access at the end of a task.

A JIT workflow looks like this. An IT administrator needs to make changes to the global email configuration in Microsoft 365. They log into their management portal and request Global Administrator access, providing a reason for the request and the expected duration. The system either approves automatically for low-risk requests or routes the request to an approver. Access is granted for the specified window — say, four hours. At the end of that window, the Global Admin role is automatically removed. Every step is logged: who requested it, why, who approved it, when it was granted, and when it was revoked.

This approach eliminates standing privileges entirely for high-risk roles. An attacker who compromises the administrator's account outside of an active JIT session finds an account with no elevated permissions — no more useful than a standard user account.

Microsoft Entra ID Privileged Identity Management (PIM) implements JIT for Microsoft 365 Global Admin and other Entra ID roles. It is available with Entra ID P2 licensing, which is included in Microsoft 365 Business Premium. For on-premises environments and more complex multi-cloud scenarios, enterprise PAM platforms such as CyberArk and BeyondTrust offer comprehensive JIT capabilities, though these are typically sized for larger organisations. For most Australian SMBs, Entra PIM provides meaningful JIT capability within their existing licensing.

Privileged Access Management for Microsoft 365

Because most Australian SMBs run Microsoft 365, the Microsoft 365 admin environment deserves specific attention. It is where the most consequential privileged access decisions are made, and where the most common mistakes occur.

Global Administrator is the highest-privilege role in Microsoft 365. A Global Admin can do anything in the tenancy — read all email, access all files, delete all accounts, modify all security settings, change billing, and disable every security control you have implemented. Microsoft recommends that a tenancy have between two and four Global Admin accounts. Fewer than two creates a risk if the primary admin is locked out. More than four means you have more accounts than you likely need at that privilege level, each of which represents a target.

Global Admin accounts must have MFA enforced, without exception. There is no scenario in which a Global Admin account operating without MFA is acceptable. A Global Admin credential stolen without MFA protection gives an attacker complete control of your Microsoft 365 environment. Conditional Access policies in Entra ID should enforce MFA for all admin roles, and for all users — but Global Admin is the non-negotiable starting point.

Use role-based access control (RBAC) to assign only the permissions each administrator needs. Microsoft 365 includes granular admin roles beyond Global Admin. An administrator who manages email does not need Global Admin — they need Exchange Administrator. Someone managing SharePoint does not need Global Admin — they need SharePoint Administrator. Someone handling security alerts does not need Global Admin — they need Security Reader or Security Administrator. Assigning the least powerful role that allows the task to be completed is RBAC applied correctly.

Use Entra PIM to make Global Admin a time-limited elevation. With Entra Privileged Identity Management, Global Admin becomes an eligible role rather than an assigned role. The administrator holds no Global Admin rights in their normal state. When they need Global Admin access, they activate it through PIM, provide a justification, and receive time-limited elevation — typically for one to eight hours. This requires Microsoft 365 Business Premium or Entra ID P2 licensing.

Break-glass accounts are emergency accounts designed for use when your normal admin access fails. Two break-glass accounts should exist in every Microsoft 365 tenancy. They are not used for day-to-day tasks. They are excluded from Conditional Access policies that might otherwise lock them out in an emergency (such as MFA policy failures or Conditional Access misconfigurations). Their credentials are stored offline — printed and locked in a physical safe, or stored in an offline credential vault. They should be monitored with an alert so that any sign-in from a break-glass account immediately triggers an investigation.

Managing MSP and Third-Party Admin Access

If you rely on a managed IT provider, your MSP likely has some form of Global Administrator or equivalent access to your Microsoft 365 tenancy. This is necessary for them to manage your environment. It also represents one of the most significant privileged access risks your business faces — not because your MSP is untrustworthy, but because their credentials and access model may not be adequately secured.

The questions you should be asking your managed IT provider about admin access:

Is the access via shared credentials or individual named accounts? If five technicians at your MSP all use a single shared admin account, there is no accountability for individual actions and no way to revoke one technician's access without changing the shared credentials for all of them.

Is MFA enforced on the MSP's access to your environment? If your MSP's admin access is not protected by MFA, a phishing attack against any of their technicians could result in immediate, unrestricted access to your Microsoft 365 tenancy — and potentially every client tenancy they manage.

Are the MSP's access sessions logged and auditable? You should be able to review a log of every admin action taken in your environment, including which account performed the action and when. If your MSP cannot tell you how to access this audit log, that is a problem.

Can you remove the MSP's access without their cooperation? This is the question that matters most if the relationship ever ends badly. Modern MSP access models are built to answer yes. The older model — where an MSP set up their own admin account inside your tenancy that you cannot see or remove without their help — is a model you should move away from.

Microsoft's modern MSP access framework uses two approaches. Microsoft 365 Lighthouse provides MSPs with a managed view across multiple client tenancies. Granular Delegated Admin Privileges (GDAP) is the current Microsoft standard for MSP access — it allows MSPs to request scoped, time-limited delegated access to specific roles in client tenancies, rather than the broad Delegated Admin Privileges (DAP) model that was standard for many years. GDAP access is visible, auditable, and controlled by the customer.

Your MSP agreement should explicitly address how admin access is managed and what the offboarding process looks like. If it does not, ask for an addendum before your next renewal.

PAM for SMBs — Practical Starting Points

Not every Australian SMB needs a full enterprise PAM platform. Many of the most impactful controls are available through tools you already have — or through straightforward process changes that require no additional software.

1. Audit all admin accounts. Start by listing every account in your environment that holds any form of administrative rights — local admin on workstations, domain admin in Active Directory, admin roles in Microsoft 365, admin access in cloud platforms, and credentials for network devices. For each account, record who holds it, when it was last used, what it was created for, and whether it is still needed. This audit will almost certainly surface accounts that no longer need to exist.

2. Remove local admin rights from standard users. Standard workstation users should not have local administrator rights. This can be enforced via Microsoft Intune (for Microsoft 365 Business Premium customers) or via Group Policy in a traditional Active Directory environment. Users who genuinely need to install software occasionally can have that process managed through a request workflow. The reduction in malware's ability to execute with elevated privileges is significant.

3. Create dedicated admin accounts. Any IT administrator should have two accounts: their standard daily-use account (which has a mailbox, is used for email and productivity work, and holds no elevated permissions) and a separate admin account (which has no mailbox, is used only for specific administrative tasks, and holds the elevated permissions required for those tasks). The admin account's name and format should make it identifiable — for example, admin-jsmith rather than jsmith.

4. Enforce MFA on all admin accounts. Every account with any form of administrative privilege must have MFA enforced. This is a baseline requirement, not an advanced control. In Microsoft 365, Conditional Access policies can enforce this automatically.

5. Implement Entra PIM for Microsoft 365. If your Microsoft 365 licensing includes Business Premium or Entra ID P2, you already have access to Entra Privileged Identity Management. Configure Global Admin as an eligible role rather than an assigned role. Require justification and approval for activation. Set a maximum activation window of four to eight hours.

6. Review MSP access. Ask your MSP to confirm they are using GDAP rather than legacy DAP. Confirm that their technicians access your environment through individual named accounts with MFA enforced. Review the Entra ID audit log to confirm you can see a record of admin activity.

7. Decommission forgotten service accounts. Review every service account in Active Directory and Microsoft 365. Any account that has not been used in 90 days should be investigated and most likely disabled. Disabling rather than deleting preserves the account if there turns out to be a legitimate reason for it, but removes the access while the review is completed.

These seven steps are not a complete PAM program. But they address the highest-risk gaps in most Australian SMB environments and can be completed without purchasing any additional tooling beyond what Microsoft 365 Business Premium already provides.

How Pickle Manages Privileged Access for Clients

Privileged access management is embedded in how Pickle delivers managed IT services to Australian SMBs, strata buildings, and commercial properties.

Pickle uses individual named accounts — not shared credentials — for all administrative work in client environments. Every technician's access is tied to a specific person. When a technician leaves Pickle, their access to client environments is revoked cleanly and completely, without affecting anyone else.

MFA is enforced on all management access. There are no exceptions and no shared accounts operating without multi-factor authentication.

For Microsoft 365 client tenancies, Pickle uses Microsoft Granular Delegated Admin Privileges (GDAP) — the current Microsoft standard for MSP access. This means Pickle's access is scoped to the specific roles required, is visible to the client in their Entra ID tenant, and can be reviewed or revoked by the client at any time without Pickle needing to cooperate. Clients retain control of their own environment.

Admin activity in client Microsoft 365 tenancies is logged in the Entra ID audit log and available for client review at any time.

If you want to understand how your current admin access is configured — or if you have inherited an IT environment and are not sure who holds admin rights to what — Pickle can conduct an access audit as part of onboarding or as a standalone engagement.

Call 1300 688 588 or email [email protected] to talk through your situation.

Frequently Asked Questions

Q: What is the difference between a privileged account and a regular user account?

A: A regular user account allows a person to perform their normal job functions — reading email, accessing files they have been granted permission to, running approved applications. A privileged account holds elevated permissions that go beyond the individual's job function: the ability to install or remove software, create or delete other accounts, change security settings, access data belonging to other users, or configure systems. The defining characteristic is that a privileged account can affect other users and systems, not just the account holder themselves.

Q: Does every Australian business need a PAM solution?

A: Every Australian business needs to manage privileged access. Whether that requires a dedicated PAM platform depends on the complexity of the environment. Many SMBs can address their highest-risk gaps using controls already available in Microsoft 365 Business Premium — particularly Entra Privileged Identity Management, Conditional Access, and Intune. Larger environments, regulated industries, or businesses with complex on-premises infrastructure may benefit from purpose-built PAM platforms. The starting point for any business is an audit of who currently holds admin rights and whether those rights are appropriate.

Q: How many Global Admin accounts should a Microsoft 365 tenant have?

A: Microsoft recommends between two and four Global Administrator accounts per tenancy. Fewer than two creates an operational risk — if the sole Global Admin is locked out of their account, there may be no way to recover access without Microsoft support involvement, which can take days. More than four is generally unnecessary and creates additional attack surface. In practice, most SMBs should maintain two Global Admin accounts for their internal IT lead (or MSP technical lead), plus two break-glass emergency accounts that are stored offline and never used for routine tasks.

Q: What happens if our IT provider's admin account is compromised?

A: The impact depends entirely on how that admin access was set up. If the IT provider used a single shared admin account with no MFA, a compromise could give an attacker full Global Admin access to your Microsoft 365 tenancy immediately and silently. If the provider uses GDAP with individual named accounts and MFA enforced, the attacker would need to compromise a specific technician's MFA-protected credentials — substantially harder — and the access would be scoped to the roles that technician had been granted. You should ask your current provider how their access to your environment is configured and confirm it aligns with the GDAP model.

Q: Is removing local admin rights from users realistic in a small business?

A: Yes, and it is one of the most impactful changes a small business can make. The practical friction is manageable with the right approach. Most users who have local admin rights have them because they were granted by default at setup, not because they genuinely need to install software regularly. For users who do occasionally need to install software, a lightweight request process — submitting a request to IT who then installs the software remotely — handles most cases. Microsoft Intune, available with Microsoft 365 Business Premium, provides tools for delivering approved software without requiring users to have local admin rights. The short-term adjustment is real. The long-term reduction in malware exposure is significant.