Identity as the New Security Perimeter

radio_button_uncheckedshort_text 1. Introduction

Identity management was born from the need to answer a simple question: who is trying to use a system? In the first computers, few operators worked in physically controlled environments. As systems came to serve hundreds or thousands of people, user accounts, passwords, centralized directories, and access control mechanisms emerged. The rise of the Internet, cloud computing, and mobile applications turned this problem into a strategic discipline known as Identity and Access Management (IAM).

This knowledge contributes directly to the protection of companies, governments, and citizens. When an organization manages identities centrally, it can reduce forgotten accounts, apply consistent policies, remove access quickly, and offer more secure digital services. For the reader, understanding identity is learning to look at security from the point of view of who is requesting access, which resource is being requested, and what evidence must be verified before allowing the action.

Throughout this chapter, the idea of “identity as the new perimeter” will stop looking like just a slogan. You will see how authentication, authorization, directories, identity providers, tokens, SSO, and federation form a logical chain. When this chain is well understood, many SC-900 scenarios become predictable: you just need to find out who asserts the identity, who verifies it, who trusts the result, and who decides what can be done.

radio_button_uncheckedshort_text 2. A brief evolution of digital identity

At the beginning of corporate computing, security relied mainly on physical barriers and control of the internal network. A user who was inside the building, connected to the domain, and using corporate equipment was frequently treated as trusted. Active Directory Domain Services, introduced by Microsoft with Windows 2000, consolidated accounts, computers, groups, policies, and authentication into on-premises domains. It solved a central challenge of the time: uniformly managing many resources of a Windows-based infrastructure.

The Internet and SaaS applications broke the correspondence between “being on the network” and “being trusted.” Users began to access data from home, from mobile devices, from public networks, and from partner organizations. Applications came to exist outside the datacenter. APIs and automated services began to act without a person present. In this context, the IP address and physical location were no longer sufficient to represent trust. Identity became the common element among all these interactions.

The change does not eliminate firewalls, segmentation, or network controls. It changes the order of priority: identity is the first line of decision, while the network works as complementary protection. In a modern architecture, each request is evaluated according to the subject, the device, the application, the risk, the resource, and the context. This reasoning brings identity closer to the principles of Zero Trust and least privilege.

radio_button_uncheckedshort_text 3. What digital identity is

Digital identity is the electronic representation of an entity within a system. The entity can be a person, a device, an application, a service, a workload or, in current solutions, an artificial intelligence agent. This representation contains an identifier and a set of attributes that make it possible to differentiate the entity from the others and to make access decisions.

An identity is not just a username. It can contain a unique identifier, display name, email address, job title, department, groups, roles, registered devices, authentication methods, account status, and relationships with applications. Some attributes describe the entity; others directly influence permissions. The quality, timeliness, and protection of these attributes affect the entire security of the environment.

Important principle

An identity describes who or what is acting. A credential is just one of the means used to demonstrate that the entity controls that identity. Changing the password does not create a new identity; it changes a credential associated with it.

radio_button_uncheckedshort_text 4. Identification, authentication, authorization, and administration

4.1 Identification

Identification is the act of an entity declaring who it is. When you type joao@company.com, select a certificate, or present an application identifier, the requester states which identity it wants to use. Identification, on its own, proves nothing. Anyone can write someone else's name; that is why it needs to be followed by authentication.

4.2 Authentication

Authentication is the process of verifying whether the entity really is who it claims to be. The system validates one or more pieces of evidence: something the person knows, such as a password; something they have, such as a phone, token, or key; something they are, such as a biometric characteristic; or a cryptographic element, such as a certificate. When the verification succeeds, the system establishes a session or issues a token that represents the result.

Authenticating does not mean allowing any action. Authentication only provides a level of confidence about the identity. A user can be authenticated and still not have permission to open a report, change a setting, or access a particular tenant.

4.3 Authorization

Authorization is the decision about what an authenticated identity can do. This decision can consider roles, groups, policies, scopes, resource ownership, data classification, and context conditions. The result normally allows or denies an action. In modern systems, authorization can also require stronger authentication, limit a session, or request approval.

A simple way to memorize it is: authentication answers “who are you?”; authorization answers “what can you do?”. The logical order is to authenticate first and authorize afterward, although applications may evaluate part of the policy before starting the sign-in process.

4.4 Identity administration

Identity administration is the set of processes used to create, maintain, provision, review, and remove identities and access. It includes registering users, groups, roles, credentials, devices, applications, guests, and service accounts. It also covers role changes, transfers between areas, leaves of absence, access expiration, and offboarding.

The term Identity and Access Management (IAM) is broader: it combines administration, authentication, authorization, governance, auditing, and protection. An organization can have technically strong authentication and still present high risk if it does not quickly remove former employees' accounts or if it keeps permissions incompatible with current roles.

radio_button_uncheckedshort_text 5. Why identity is the new perimeter

The traditional perimeter was a network boundary: on one side, the internal network; on the other, the Internet. This model worked better when applications, data, users, and devices were in the same location. Today, corporate applications are distributed across Azure, Microsoft 365, other providers, and on-premises datacenters. People work from anywhere and partners need to collaborate without being part of the internal network. The boundary is no longer fixed.

Identity remains present in all these scenarios. It is possible to evaluate the identity of a person accessing a SaaS application, of a virtual machine calling a service, of an application consuming an API, or of a guest from another organization. For this reason, controls and detections are centralized around identities. The decision does not depend only on where the request came from, but on who is requesting, from which device, with what level of risk, and for which resource.

• Applications and data are outside the traditional corporate network.
• Personal and mobile devices make location less reliable.
• External users and partners need to access specific resources.
• Automated services and APIs require their own identities.
• Stolen credentials can allow remote access without breaching a firewall.
• A central identity makes it possible to apply policies and auditing consistently.

Relationship with Zero Trust

Treating identity as the perimeter does not mean automatically trusting whoever has an account. On the contrary: each request must be verified explicitly, receive the least privilege necessary, and be monitored under the assumption that a breach can occur.

radio_button_uncheckedshort_text 6. Identity infrastructure and its pillars

An identity infrastructure is the set of services, processes, policies, and integrations that supports the lifecycle and access decisions. The official Microsoft Learn module highlights four conceptual pillars: administration, authentication, authorization, and auditing. They work as interdependent parts of the same system.

These pillars need to share a source of truth. If the human resources system records an offboarding, administration must disable or remove the identity; authentication must prevent new sign-ins; authorization must revoke tokens and access; and auditing must record the process. The failure of any step leaves an opening.

radio_button_uncheckedshort_text 7. Identity providers and modern authentication

An identity provider, or Identity Provider (IdP), is a central service that creates and maintains identity information and offers authentication, authorization, and auditing for applications and services. Instead of each application storing its own list of users and implementing password rules, applications delegate the process to the IdP. Microsoft Entra ID is an example of a cloud-based identity provider.

When a user tries to sign in to an application, it redirects them to the identity provider. The IdP verifies the credentials and applies policies. If the process is approved, it issues a security token. The application validates the token based on its trust relationship with the IdP and uses the information contained in it to create the session and decide access.

Centralizing authentication brings clear benefits: consistent policies, MFA across multiple applications, unified visibility of sign-ins, reduction of independent passwords, faster deprovisioning, and a greater ability to detect suspicious patterns. It also reduces the risk of each team trying to develop its own authentication mechanism, a complex and sensitive task.

radio_button_uncheckedshort_text 8. Tokens, claims, and protocols

8.1 Security tokens

A security token is a structured package of data issued by a trusted authority after authentication. The token prevents the application from receiving and validating the user's password directly. Instead, it receives evidence signed by the identity provider. Tokens normally have an issuer, an audience, an issuance time, an expiration, and information about the subject.

Two types are important for conceptual understanding. The ID token proves that the user was authenticated and states who they are. The access token represents authorization to access a resource or API. An ID token should not be used as a substitute for an access token when calling an API; they have distinct purposes.

8.2 Claims

Claims are individual statements carried in a token. Examples include the user identifier, name, email, groups, roles, tenant, authentication method, time, and authorized scope. The application should not accept a claim just because it exists; it must validate the token signature, the issuer, the audience, the validity, and other protocol requirements.

8.3 Modern authentication protocols

A frequent trap

OAuth 2.0 is an authorization framework. OpenID Connect adds an authentication layer on top of OAuth 2.0. SAML can also provide SSO, but uses a different model and format.

radio_button_uncheckedshort_text 9. Single Sign-On (SSO)

Single sign-on is the ability of a user to authenticate once with an identity provider and access several trusted applications without providing the credentials again at each sign-in. This is possible because the IdP maintains a session and issues tokens specific to the requested applications. Each application validates the token and trusts the result of the authentication performed by the IdP.

SSO improves the experience and can strengthen security. Fewer password prompts reduce reuse, fatigue, and exposure to fake pages. The organization can apply MFA and policies at a central point. However, centralization increases the importance of protecting the account and the IdP: if a central identity is compromised, multiple applications can be affected. For this reason, SSO must be accompanied by strong authentication, monitoring, and least privilege.

SSO is not the same as federation. SSO describes the experience of authenticating once and accessing several applications. Federation describes the trust relationship between distinct identity systems. A federated solution can provide SSO between organizations, but SSO also exists within a single provider.

radio_button_uncheckedshort_text 10. Directory services

A directory service is a system specialized in storing, organizing, searching, and managing information about identities and resources. It works as a structured source for users, groups, computers, applications, and other objects. Unlike a simple list of accounts, a directory offers hierarchy or relationships, attributes, policies, query mechanisms, and integration with authentication and authorization.

Directories help maintain a consistent identity. A group can represent a team; a role can grant permissions; an attribute can drive provisioning. Applications query the directory or trust the identity provider connected to it. The directory, by itself, does not replace all IAM components, but it is a central piece of the infrastructure.

• Store identity objects and attributes.
• Organize users, groups, devices, and applications.
• Allow efficient searches and queries.
• Support authentication and access policies.
• Provide a common source for provisioning and auditing.
• Maintain membership relationships, such as users belonging to groups.

radio_button_uncheckedshort_text 11. Active Directory Domain Services (AD DS)

Active Directory Domain Services is Microsoft's directory service for Windows Server domains. It organizes objects into a structure made up of forests, domains, and organizational units. Domain controllers store the directory, authenticate users and computers, and replicate information among themselves. AD DS is deeply integrated with DNS and uses protocols such as Kerberos, NTLM, and LDAP.

A forest represents the broadest boundary of an AD DS deployment and can contain several domains. A domain gathers objects that share a database, policies, and a namespace. Organizational units help organize objects and delegate administration, but they are not security boundaries equivalent to a forest. Groups are used to assign permissions and simplify administration.

AD DS is especially suitable for on-premises resources, Windows integrated authentication, servers, domain-joined workstations, and legacy applications. The organization is responsible for installing, updating, protecting, monitoring, and ensuring the availability of the domain controllers.

radio_button_uncheckedshort_text 12. Microsoft Entra ID

Microsoft Entra ID is Microsoft's cloud-based identity and access management solution. It connects people, devices, applications, and data and works as an identity provider for Microsoft 365, Azure, and thousands of applications. It is a multitenant service operated by Microsoft and offered as Identity as a Service (IDaaS).

The central administrative unit is the tenant, also called the Microsoft Entra directory. The tenant has a unique identifier and contains users, groups, devices, application registrations, service principals, roles, and policies. Modern authentication uses protocols such as OAuth 2.0, OpenID Connect, and SAML. The service offers SSO, MFA, Conditional Access, identity protection, governance, and provisioning integrations.

Microsoft Entra ID is not simply a domain controller in the cloud. It does not use forests, domains, and organizational units like AD DS and does not depend on Kerberos or LDAP as the main interface for modern applications. Its architecture was created for the Internet, SaaS, APIs, and distributed environments. When applications require traditional domain features, other solutions, such as on-premises AD DS or Microsoft Entra Domain Services, may be necessary.

• Central identity management for cloud and hybrid environments.
• Authentication for Microsoft 365, Azure, and integrated applications.
• SSO and federation with organizations and external providers.
• Identities for users, devices, applications, and workloads.
• Access policies based on context and risk.
• Sign-in logs, auditing, governance, and identity protection.

radio_button_uncheckedshort_text 13. Active Directory Domain Services vs. Microsoft Entra ID

Watch the terminology

Microsoft Entra ID was called Azure Active Directory (Azure AD). The name change did not turn the service into AD DS. In exam questions, note whether the scenario involves a Windows domain and traditional protocols or cloud identity and modern authentication.

radio_button_uncheckedshort_text 14. Trust between domains

In Active Directory Domain Services, a trust relationship allows identities authenticated in one domain to be recognized to access resources in another domain, according to the configured permissions. Trust does not grant access automatically; it creates a path for the authentication to be accepted. Authorization on the target resource is still necessary.

Trusts can have direction and transitivity. A one-way trust allows one side to accept identities from the other in a specific direction. A two-way trust establishes recognition in both directions. Transitive trusts can extend the path between related domains, while a non-transitive trust is limited to the configured parties.

In the SC-900, the most important thing is to understand the idea of trust and not to memorize all the administrative variations of AD DS. The same general notion appears in federation: one party accepts evidence of identity issued by another trusted party.

radio_button_uncheckedshort_text 15. Identity federation

Federation is the establishment of trust relationships between separate identity systems to allow access across organizational or domain boundaries. The user authenticates with their organization's provider and uses that identity to access an external resource. The target system does not need to store the user's password or manage a separate credential.

The passport analogy is useful: one country issues a document and another accepts it as evidence because it trusts the issuer and can verify its authenticity. In federation, the identity provider issues a token or assertion; the target application or provider validates the signature, the issuer, the audience, and the claims. Then, it applies its own authorization rules.

Federation can use SAML, OpenID Connect, WS-Federation, or other compatible protocols. Active Directory Federation Services (AD FS) is a server role that makes it possible to issue tokens from AD DS identities and integrate them with external applications. Microsoft Entra ID also offers federation and external collaboration without requiring each application to implement all these details directly.

radio_button_uncheckedshort_text 16. Authentication between organizations, applications, and external providers

16.1 Collaboration between companies

In a partnership between companies, employees of Organization B can access a project hosted by Organization A using their corporate credentials. Organization A trusts the authentication performed by B's provider or uses B2B collaboration features. Authorization remains under A's control: only the necessary documents, groups, and applications should be released.

16.2 Social and consumer providers

A public-facing application can allow sign-in with Microsoft, Google, GitHub, or other provider accounts. The application trusts the external provider to authenticate the person and receives basic claims. This reduces registration friction, but the application still needs to create its internal profile, apply consent, protect personal data, and define permissions.

16.3 An application accessing an API

An application can receive authorization to call an API on behalf of the user or on its own behalf. In the first case, the access token represents a combination of the application, the user, and the granted scopes. In the second, the application uses a service identity, certificate, or managed identity. In both, the API validates the token before authorizing the operation.

16.4 Hybrid identity

Hybrid identity allows the same person to have a consistent representation in on-premises and cloud environments. Organizations that use AD DS can synchronize users and attributes to Microsoft Entra ID. Depending on the design, authentication can occur in the cloud, use agents, or be federated with on-premises infrastructure. The goal is to offer a common identity without forcing the user to maintain disconnected accounts.

radio_button_uncheckedshort_text 17. Lifecycle, provisioning, and deprovisioning

Identity security does not end at sign-in. Each identity goes through a lifecycle: joining, changes, and leaving. This model is often described as joiner, mover, and leaver. On joining, the organization creates the identity, assigns attributes, and grants initial access. On a role change, old permissions must be removed and new permissions granted. On leaving, sessions, tokens, devices, and access need to be revoked quickly.

Provisioning is the creation and updating of identities and accounts in target systems. It can be manual, automated by HR integrations, or standardized with SCIM. Deprovisioning is the coordinated removal or deactivation. A forgotten account in a non-integrated application can remain accessible even after the central identity has been disabled; for this reason, inventory and automation are important.

1. An authoritative source records the person's link, such as the HR system.
2. The directory or IdP creates the identity and its attributes.
3. Groups, roles, and access packages grant the minimum necessary.
4. Applications receive or create accounts through provisioning.
5. Role changes trigger a review and adjustment of permissions.
6. Offboarding disables authentication, revokes sessions, and removes access.
7. Logs and reviews verify that the process was completed.

The principle of least privilege

An identity should receive only the necessary permissions, in the necessary scope, and for the necessary time. The lifecycle prevents privileges from accumulating indefinitely.

radio_button_uncheckedshort_text 18. Identity-based risks and attacks

If identity is the new perimeter, attackers will try to cross it. The goal may be to steal a credential, deceive the user, reuse a session, register an authentication method, or obtain additional privileges. Knowledge of these risks helps to understand why centralization, MFA, short-lived tokens, auditing, and deprovisioning are relevant.

No isolated control eliminates all risk. MFA reduces the value of a stolen password but does not fix excessive authorization. SSO reduces the number of credentials but requires rigorous protection of the central provider. Auditing allows detecting and investigating, but needs to be accompanied by response processes.

radio_button_uncheckedshort_text 19. How the concepts connect

Consider an employee's access to a cloud payroll application. The identity was created from the hiring process and received department attributes. When opening the application, she provides her identifier. The application redirects the browser to Microsoft Entra ID, which authenticates the user and applies policies. An ID token states who she is; an access token allows calling a specific API. The application analyzes the claims and authorizes only the screens appropriate to her role.

If the employee accesses a partner application, a federated relationship can allow the use of the same identity. If the organization maintains on-premises AD DS, the identity can be synchronized to Microsoft Entra ID and used in a hybrid way. When the employee changes areas, administration updates attributes and groups; permissions are recalculated. On offboarding, the account is disabled, sessions are revoked, and integrated applications remove access.

This example shows that directory, IdP, SSO, and federation are not independent concepts. The directory organizes identities; the IdP authenticates them and issues tokens; SSO improves the experience across trusted applications; federation extends trust between distinct systems; authorization protects each resource; and auditing records the entire path.

radio_button_uncheckedshort_text 20. Common traps in the SC-900

radio_button_uncheckedshort_text 21. Integrated scenario: collaboration between two companies

Company Alpha uses Microsoft 365 and hosts a project portal. Company Beta participates in the project and needs to grant access to twenty consultants. The goal is to avoid separate accounts and passwords on the portal, ensure that Beta remains responsible for authenticating its professionals, and allow Alpha to control exactly which resources can be accessed.

21.1 Identity architecture

• Each company maintains its own identity provider and user lifecycle.
• Alpha establishes B2B collaboration or a compatible federated relationship.
• The consultants sign in with Beta's corporate credentials.
• Alpha receives an external identity and assigns groups or roles limited to the project.
• The portal trusts Alpha's IdP and receives tokens with relevant claims.

21.2 Access flow

1. The consultant provides their identity on Alpha's portal.
2. The flow identifies that the authentication must be performed by Beta's trusted provider.
3. Beta authenticates the user and issues evidence or participates in the federated flow.
4. Alpha validates the trust and represents the consultant as an external user.
5. The portal receives a token and authorizes only the project workspace.
6. Sign-ins and actions are recorded for auditing.

21.3 Change and offboarding

If a consultant leaves Beta, their identity provider must prevent new authentications. Alpha should also have access reviews and expiration to reduce dependence on manual processes. At the end of the project, the group and external access are removed. This design combines federation, SSO, local authorization, least privilege, and lifecycle governance.

Result

Beta controls the authentication of its professionals; Alpha controls the authorization over its resources. No corporate password needs to be shared with the other company's portal.

radio_button_uncheckedshort_text 22. Quick review for the exam

radio_button_uncheckedshort_text 23. Conclusion

Identity became the new perimeter because modern security cannot depend only on a network boundary. People, devices, applications, and services access resources distributed across cloud, SaaS, and on-premises environments. Identity offers a common point to verify who requests access, evaluate the context, apply least privilege, and record decisions.

In this chapter, we differentiated identification, authentication, authorization, and administration; we analyzed the pillars of an identity infrastructure; we explained the role of the identity provider, tokens, and claims; and we separated SSO from federation. We also compared Active Directory Domain Services and Microsoft Entra ID and showed how trust and standardized protocols allow collaboration between organizations.

In my assessment, identity is the topic that most helps the candidate understand the rest of the SC-900. MFA, Conditional Access, identity protection, RBAC, PIM, governance, and external collaboration are natural extensions of the fundamentals studied here. When you can narrate the complete flow - from account creation to token issuance and resource authorization - you stop memorizing isolated products and start understanding the architecture. This change of perspective makes the study more consistent and paves the way for the next chapters on Microsoft Entra ID.

radio_button_uncheckedshort_text 24. Review questions

Try to answer before consulting the commented answer key.

Question 1

A user enters their email address and then confirms a request in Microsoft Authenticator. Which steps occurred, respectively?

• A) Authorization and auditing.
• B) Identification and authentication.
• C) Authentication and identification.
• D) Provisioning and authorization.

Commented answer key

Correct answer: B. Entering the address declares the identity; confirming the evidence verifies that the user controls that identity.

Question 2

Which statement correctly describes single sign-on?

• A) All applications store the same user password.
• B) The user receives unrestricted authorization after the first sign-in.
• C) The user authenticates with the IdP and trusted applications accept tokens without requiring the credentials again.
• D) SSO only works between two AD DS domains.

Commented answer key

Correct answer: C. SSO depends on trust in the identity provider and on tokens; it does not share the password or eliminate authorization.

Question 3

Which difference between AD DS and Microsoft Entra ID is correct?

• A) Microsoft Entra ID is just a domain controller operated by Microsoft.
• B) AD DS mainly uses OAuth 2.0, while Entra ID uses Kerberos.
• C) AD DS serves Windows domains and traditional protocols; Entra ID is a cloud IAM/IdP for SaaS, applications, and modern APIs.
• D) The two products have exactly the same structure of forests and OUs.

Commented answer key

Correct answer: C. They deal with identity, but have different architectures, protocols, and scenarios, and can coexist in hybrid environments.

Question 4

A company accepts tokens issued by a partner's identity provider. What does this represent?

• A) Symmetric encryption.
• B) Identity federation.
• C) Only local identification.
• D) Automatic permission to all resources.

Commented answer key

Correct answer: B. Federation establishes trust between identity systems. The target company must still authorize each resource.

radio_button_uncheckedshort_text 25. References and further reading

Content of the SC-900 study plan provided by the user: Chapter 2 - Identity as the New Security Perimeter.

• Microsoft Learn. Study guide for Exam SC-900: Microsoft Security, Compliance, and Identity Fundamentals. Updated on June 26, 2026; consulted on July 23, 2026.
• Microsoft Learn. Describe identity concepts. SC-900 training module; consulted on July 23, 2026.
• Microsoft Learn. Describe the role of the identity provider. Unit on IdP, tokens, claims, protocols, and SSO; consulted on July 23, 2026.
• Microsoft Learn. Describe the concept of federation. Unit on trust between providers and external collaboration; consulted on July 23, 2026.
• Microsoft Learn. Compare Active Directory to Microsoft Entra ID. Microsoft Entra fundamentals documentation.
• Microsoft Learn. Azure identity management and access control security best practices. Documentation on identity as the perimeter and IAM centralization.
• Microsoft Learn. Introduction to Microsoft Entra and Describe the function and identity types of Microsoft Entra ID. Official learning paths.

Chapter wrap-up

You have completed the conceptual foundations of identity. The natural next step is to study the structure of Microsoft Entra ID, its identity types, and the integration between on-premises and cloud environments.