Securing External Identities and Privileged Access

Let’s start with the most basic idea: an 'identity' is simply a digital representation of a person, device, or service that needs to access something. In your home, you have a physical key for your front door. In IT, you have a 'digital identity' — usually a username and password. Now, 'external identities' are identities that belong to people who are not employees of your organisation. Think of a consultant who helps fix your database, a supplier who needs to update inventory, or a customer logging into a portal. They are not on your payroll, but they need access to specific parts of your digital house.

Microsoft Entra ID (formerly called Azure Active Directory) is the system that manages these identities. It is a cloud-based directory service that stores information about users and controls who can access what. Before cloud computing, companies had to install their own servers (called 'on-premises' servers) to manage identities. That was expensive and hard to maintain. Microsoft Entra ID does it for you in Microsoft’s data centres.

Now, how do you let an external person in? The most common method is 'B2B collaboration' (Business-to-Business). Your company uses Microsoft Entra ID, and so does the partner company. Your admin sends an invitation. The partner user accepts it. Microsoft Entra ID then trusts the identity that already exists in the partner’s own system. The partner user does not need a new username and password. They just use their own company credentials. This is called 'federation' — one system trusts the authentication done by another system.

But you cannot give external people the same access as employees. That would be a security disaster. So you use 'conditional access policies'. These are rules like: 'If the user is external, and they are trying to access the finance folder, block them unless they are on a managed device.' Or: 'If the user is external, require multi-factor authentication (MFA) — that is, a second verification like a code texted to their phone.' These policies are enforced by Microsoft Entra ID every time someone tries to sign in.

Now, let’s talk about 'privileged access'. This is the big brother of access control. 'Privileged' means having higher permissions than a normal user. For example, an IT administrator can reset user passwords, create new user accounts, change security settings, or delete entire databases. If a criminal gets hold of an admin account, they can destroy the entire company’s IT systems. So special protections are needed.

Microsoft’s solution is 'Privileged Identity Management' (PIM). PIM is a service inside Microsoft Entra ID that does two main things. First, it makes admin accounts 'just-in-time' (JIT). Normally, an admin account is always active, 24/7. With JIT, the admin account is disabled by default. When the admin actually needs to do a task, they must request activation through PIM. They get approved (or automatically approved if policy allows), and then the account is enabled for a limited time — say one hour. After that hour, it is disabled again. This reduces the 'attack surface' — the amount of time a powerful account is exposed to potential attack.

Second, PIM uses 'approval workflows'. For very sensitive roles (like 'Global Administrator' which can do everything), a request to activate might need approval from a manager. PIM also requires 'auditing' — every activation, every change, is logged. So if something goes wrong, you can see exactly who had power when.

Finally, there is 'Privileged Access Management' (PAM) for managing local admin accounts on servers and devices, but for the SC-100 exam, you focus mostly on PIM in Microsoft Entra ID for cloud identities. The key principle is 'least privilege': give every person, external or internal, exactly the minimum access they need to do their job and no more. If a vendor only needs to read a report, do not give them permission to upload files. If a junior admin only needs to reset passwords for the sales team, do not give them Global Admin rights.

Why does this exist? Because in the old days, companies gave everyone too much access because it was easier. The result: when a contractor left, their credentials were never revoked, and a hacker could use them months later. Or a disgruntled employee with too much power could delete everything. Modern identity security is built on 'Zero Trust' — a model that says 'never trust, always verify' and 'assume breach'. This means you treat every access request, even from inside your network, as if it could be an attacker, until proven otherwise. For the SC-100 exam, you must be able to design a solution that incorporates these principles for both external identities and privileged roles.

A real IT professional — let’s call her Sarah — is the identity security architect for a mid-sized company called 'NovaTech' with 2,000 employees and 500 external partners. NovaTech uses Microsoft Entra ID. One day, Sarah gets a request from the sales director: they want to give a consultant from 'DataCrunch Inc.' access to the sales analytics dashboard. The consultant needs to see real-time numbers but should not be able to change any data or download the underlying database.

Sarah logs into the Microsoft Entra admin centre. She navigates to 'External Identities' and clicks 'New guest user'. She enters the consultant’s email address — john.doe@datacrunch.com. She then selects 'Invite'. John receives an email with a link. He clicks it and signs in using his DataCrunch Microsoft Entra ID account.

Now, Sarah must set the right permissions. She does not add John to a high-privilege group. Instead, she creates a new group in Microsoft Entra called 'Sales Analytics Viewers - External'. She adds John’s guest account to that group. Then she goes to the 'Enterprise Applications' section, finds the Sales Analytics app, and assigns that group with a role called 'Reader'. The Reader role only allows viewing dashboards — no edit, no delete.

Next, Sarah sets up a conditional access policy. She creates a policy that targets all guest users. The policy says: 'Require multi-factor authentication and require a device that is compliant (managed by a company policy).' This ensures John must use his phone to get a code and his laptop must be trusted. She also adds a 'session control' that limits the user’s browser session so they cannot copy data to clipboard or print the screen. This is called 'session management' or 'app control'.

Now, for privileged access. NovaTech has three Global Administrators — the top-level admins. Sarah implements Microsoft Entra Privileged Identity Management (PIM). She configures the Global Admin role to require 'elevation'. This means the three admins do not have standing Global Admin rights. Every time one of them needs to perform a Global Admin task (like changing a security policy), they must go to the PIM portal, request activation, and provide a reason. The activation is automatically approved (because they are trusted) but only lasts for one hour. Sarah also sets up an alert: if any Global Admin role is activated outside of business hours, the security team gets a notification.

She also configures 'Access Reviews' for external identities. Every three months, Microsoft Entra ID automatically sends an email to the sales director asking: 'Do John Doe and the other 15 external guests in the Sales Analytics Viewers group still need access?' If the sales director does not respond within two weeks, the access is revoked automatically. This prevents 'stale access' — old accounts that nobody remembers are still dangerous.

Finally, Sarah monitors the 'Sign-in logs' and 'Audit logs' weekly. She looks for anomalies: an external user trying to access the HR portal, or an admin account being activated unusually often. She uses Microsoft Sentinel (a security information and event management tool) to correlate these logs and detect potential attacks. The step-by-step reality of this job is ongoing, not a one-time setup. It demands constant vigilance, regular policy reviews, and user training.