A global organization uses Microsoft Entra ID for employee access, runs legacy applications in a data center, and has automation accounts in several clouds. Its audit finds that human administrators are generally well protected, but workload identities have broad permissions and some third-party integrations use credentials that no one has rotated in years. The company does not have a single ‘identity problem.’ It has different identity classes, trust relationships, and lifecycle responsibilities that were never designed as one security system.
The Microsoft SC-100 architect must turn identity risk into a coherent enterprise strategy. Microsoft’s current July 2026 outline covers identity, infrastructure, security operations, data, applications, and hybrid or multicloud conditions. Identity architecture is not only implementing a sign-in policy. It includes provisioning, privileged delegation, federation, workload credentials, session controls, auditability, and reliable recovery when a component fails.
Build an inventory of identities and privileges
Start by identifying workforce users, guests, administrators, applications, managed identities, service principals, and nonhuman automation accounts. Each class has a different owner and lifecycle. An employee identity normally follows joining, role changes, and departure. A service principal may outlive the team that created it. A third-party integration may retain access after a contract ends. Without inventory and ownership, organizations cannot evaluate whether access is still justified.
Classify privileges by impact, not by attractive role names. A workload identity with rights to read all customer data can create as much risk as an administrator role that changes infrastructure. Consider access to identity configuration, keys, security telemetry, production deployment, and data exports. High-impact identities deserve stronger monitoring, more restrictive authorization, and explicit review even when they never appear in the interactive sign-in logs familiar to help desks.
Ownership must be practical. If a service account is marked ‘IT’ and nobody knows who can approve its removal, it has no useful owner. Tie identities to applications, accountable teams, business purposes, and supported recovery procedures. This metadata becomes essential during an incident when an operator must know whether disabling a suspicious account will stop a critical service.
Design authentication by risk and user context
Multifactor authentication is an important control, but not all factors and sessions provide the same resistance to phishing and token theft. Architect authentication methods according to privileged access, device context, application sensitivity, and user constraints. Policies should not create long-lived exceptions that become easier paths for an attacker than the normal employee experience.
Conditional Access can use supported signals such as user group, application, sign-in risk, and device-related context to govern access. Its impact depends on accurate targeting and thoughtful exclusions. A rule designed for routine office users may break a service desk’s emergency process if administrators forget how recovery access is maintained. Test policies with representative identities and controlled break-glass accounts before organization-wide enforcement.
User experience affects security. If access to a vital service repeatedly fails without a clear support route, employees may share credentials or shift work to ungoverned systems. A mature architecture offers safe troubleshooting, predictable enrollment, and recovery without permanently lowering policy. Strong authentication works best when legitimate users can complete work through supported procedures.
Control privilege as a temporary responsibility
Least privilege is not merely removing an ‘administrator’ checkbox. Break tasks into routine operations and sensitive changes, and define which roles need each permission. Privileged Identity Management can support just-in-time assignment or activation for suitable roles, with governance and monitoring. Standing broad access should be reduced when operationally possible, but emergency access must be available and tested when the normal identity service is impaired.
Approval should be proportional to impact. Viewing a support dashboard is different from changing domain federation or deleting production audit evidence. For sensitive operations, require the appropriate identity, context, and authorization workflow, and record what changed. Beware of privilege paths that cross systems: an engineer who can modify a pipeline or credential store may indirectly gain permissions much broader than their nominal cloud role.
Administrative workstations and endpoint conditions matter because privileged credentials can be compromised at the device layer. Isolated administrative practices, managed devices, and detection can reduce exposure. These controls complement privilege restrictions rather than replace them. A privileged role whose session is stolen remains dangerous even when the initial sign-in used a strong authentication method.
Treat workload identities as first-class security subjects
Applications need credentials or federated identities to access services, but embedded client secrets are frequently copied into repositories or long-lived configuration. Where supported, managed identities and workload identity federation can reduce dependence on stored passwords and keys. Their value comes from short-lived or managed credential mechanisms paired with narrow permissions, not from being magical identities that require no policy review.
Workload identity permissions should map to a specific service function. A document converter that reads one source container and writes to one output location should not receive full storage account administration. Access paths may cross Azure resources, Microsoft APIs, and external cloud services; each boundary needs careful assessment. Authorization can be constrained through application roles, resource-specific permissions, and other platform controls as appropriate.
Credential rotation and decommissioning are operational requirements. A production service using a certificate or secret needs a safe replacement process before expiration. Removing a compromised credential may require simultaneous application deployment. Map these dependencies and rehearse rotation so identity security improvements do not create avoidable outages.
Design federation and guest access carefully
Federation permits users or workloads from one identity domain to access another system under a trust relationship. It can simplify access for partners and acquired business units, but trust assumptions must be explicit. Who operates the source identity provider, what assurances exist around authentication, and how can the receiving organization revoke access? Treating any federated token as inherently trustworthy ignores these governance questions.
Guest collaboration presents similar challenges. An external contractor may need access to one project workspace but not the entire tenant’s internal knowledge. Define invitation ownership, approval, allowed resources, and periodic review. When the engagement ends, revoke or expire access in the relevant systems. Long-lived guest accounts with unclear ownership often become invisible pathways into material that was shared for convenience.
Mergers and reorganizations can introduce duplicate identities, inconsistent domain trust, and administrative overlap. Plan migrations with attention to existing permissions and audit continuity. A rushed identity consolidation can grant accidental access if groups with similar names have different meanings. Use staged mapping, negative access tests, and rollback arrangements rather than relying on directory synchronization as a complete security plan.
Connect identity telemetry to incident response
Sign-in events, risky session changes, privilege activations, workload credential use, and unusual application consent can provide evidence of identity attacks. Security teams need enough telemetry to correlate these across endpoint, application, and cloud environments. A flood of isolated alerts is not the same as visibility into a suspicious sequence that began with credential theft and ended in sensitive data access.
Design detection around plausible abuse. Unexpected consent for a high-permission application, a new credential on a service principal, or an unusual privilege activation may deserve investigation. The exact severity depends on context: a scheduled deployment pipeline and an unknown interactive actor should not be treated identically. Response playbooks need a way to determine ownership and revoke access safely without blindly disabling critical production integrations.
Session revocation, credential replacement, device isolation, and investigation of downstream changes may all be needed after a compromise. Disabling a username alone may leave active sessions or workload credentials that require separate containment. Test recovery, document escalation, and preserve evidence under appropriate privacy and retention controls. An incident that reaches multiple identity systems requires coordinated containment rather than each team clearing its own dashboard independently.
Govern identity as an ongoing lifecycle
Identity architecture needs measurable processes: time to remove departed users, proportion of privileged roles with time-bounded activation, coverage of strong authentication, number of unowned workload identities, and frequency of stale access grants. Use these measures to direct improvements, not to create meaningless scorecards. A small number of highly privileged stale identities may be more dangerous than thousands of low-impact dormant test accounts.
Collaboration across IAM, application engineering, security operations, compliance, and business ownership is essential. A permission cannot be reviewed adequately without understanding why the business needs it. Related Microsoft identity administration practices provide operational details, while SC-100 frames the architecture and risk decisions. The architect should make exceptions transparent, reduce standing privilege, and keep trust relationships easy to explain.
A secure identity estate is not one in which every sign-in succeeds after MFA. It is one in which every principal has a known purpose, access is narrow and contextual, high-impact changes are controlled, and compromised trust can be revoked quickly. That is how identity becomes a reliable foundation for Zero Trust rather than a sprawling directory whose privileges no one can fully defend.
Identity lifecycle design must account for machine-to-machine dependencies during personnel changes. When a developer leaves, the application they maintained may still need its production role, but its access approval owner must change. Similarly, rotating a certificate may affect an automated job that runs once per quarter and is absent from normal telemetry. Inventory periodic as well as continuous use, and require teams to rehearse revocation and recovery for important nonhuman principals before deciding that an identity is safe to remove.
The review process should also include denied access evidence. Frequent failures from a legitimate application may indicate a misconfigured role, while repeated attempts from unexpected locations may reveal abuse. Classify and investigate those signals without turning every denial into an incident. Good identity monitoring distinguishes operational defects from malicious behavior and creates a record that informs future access design.