A consultant is removed from a project but still has access to a SaaS workspace, a shared repository, and a privileged automation account created during the engagement. The organization’s central directory shows that the consultant’s primary account was disabled. Security leadership therefore believes access has ended. It has not. The identities and entitlements involved belong to different systems, and no one has tested whether the termination event reached them all. This is the kind of gap an architect must identify before it becomes an incident.<\/p>\n
The SC-100<\/a><\/strong> exam treats identity and access as part of an enterprise security design spanning hybrid, SaaS, PaaS, IaaS, and multicloud resources. Microsoft’s July 2026 outline includes Microsoft Entra ID, modern authentication, privileged access, workload and agent identities, Active Directory Domain Services, and governance. The architectural question is not simply whether users can sign in. It is whether every identity has only the access necessary for its current purpose, and whether that access can be understood and revoked.<\/p>\n Human employees are only one category of identity. Organizations also rely on contractors, guests, external partners, service principals, managed identities, applications, devices, and increasingly agents operating within defined services. Each category has a different lifecycle. An employee might have a date of hire and a manager; a workload identity may exist only as long as a deployment; a guest may require periodic sponsorship; a service account might survive for years because nobody remembers what depends on it.<\/p>\n Start an identity architecture by tracing who or what acts on which resource and why. In a payroll process, the interactive human user may approve a change while an application identity moves approved data between systems. That application should not inherit broad administrative access merely because the administrator who first configured it possessed such privileges. The design needs separate ownership, credentials or trust methods, authorization, and auditability for each principal.<\/p>\n This inventory exposes a frequent failure: technical accounts are treated as permanent infrastructure rather than temporary authority. Forgotten app registrations, secrets embedded in deployment scripts, and long-lived service accounts can bypass the controls applied to employees. A well-designed identity program requires owners to justify these accounts, monitor their use, and remove them when the underlying process ends.<\/p>\n Authentication proves something about the actor and the interaction, but access decisions may also depend on risk, device status, application, location, and the sensitivity of the action. Microsoft’s Entra Conditional Access<\/a> capabilities let organizations express many of those conditions. Architecture begins by defining which scenarios deserve stronger assurance and what should happen when a condition cannot be met.<\/p>\n An employee viewing a low-sensitivity intranet item from a managed device may need a different experience from an administrator changing identity policy. A user with an elevated sign-in risk may need to reauthenticate, satisfy additional requirements, or be blocked depending on organizational policy. These are not choices to make at random. They should follow the protected resource’s risk, the expected user population, and the damage an incorrect decision could cause.<\/p>\n Resilience matters here too. A rushed blanket policy can lock out legitimate administrators or interrupt a mission-critical workflow. Architects need a controlled rollout process, test populations, documented exclusions with owners, and verified emergency-access arrangements. An exception that is granted for a migration and never expires becomes a permanent bypass. Exception management is as much a part of the access design as the primary policy.<\/p>\n Standing privilege allows a compromised account to do serious damage immediately. A more disciplined design makes elevated access time-limited, purpose-based, and reviewable. Microsoft Entra Privileged Identity Management can support just-in-time activation and governance, but its configuration should follow an enterprise access model that separates administration of identities, infrastructure, and business data. The goal is to prevent one compromised role from controlling every layer at once.<\/p>\nFirst identify every kind of principal<\/h2>\n
Conditional Access should enforce business context<\/h2>\n
Make privilege temporary and observable<\/h2>\n