Microsoft Intra ID Privacy Guide

Microsoft Entra ID (formerly Azure Active Directory, renamed 2023) is identity and access management platform owned and operated by Microsoft Corporation, publicly traded company headquartered in Redmond, Washington. Part of Microsoft's comprehensive cloud productivity and security ecosystem, Entra ID provides foundational identity layer for Microsoft 365, Azure, and thousands of third-party SaaS applications, serving as authentication and authorization backbone for hundreds of millions of daily users worldwide.

According to product family structure, Microsoft Entra encompasses multiple identity-related services including Entra ID (core identity and access management previously known as Azure AD), Entra External ID (customer-facing identity combining formerly separate Azure AD External Identities B2C and B2B Direct Connect products, with FedRAMP High authorization for US government use cases), Entra ID Governance (advanced lifecycle management, access reviews, entitlement management, Privileged Identity Management for enterprise governance), Entra Verified ID (decentralized identity using verifiable credentials for credential verification without sharing raw data), Entra Permissions Management (cloud infrastructure entitlement management monitoring and controlling permissions across AWS, Azure, GCP), and Entra Workload Identities (managing machine identities, service principals, managed identities for non-human authentication including AI agents and automated workloads).

Service capabilities according to Entra ID feature set include Single Sign-On (SSO enabling users to authenticate once and access cloud and on-premise applications with pre-built integrations covering thousands of SaaS applications including Microsoft 365, Salesforce, ServiceNow, Workday, Box and custom SAML/OIDC/WS-Fed integrations), Multi-Factor Authentication (Microsoft Authenticator app push notifications and passwordless, FIDO2 security key authentication, Windows Hello for Business biometric authentication, SMS and voice call OTP, OATH hardware and software tokens, certificate-based authentication), Passwordless Authentication (FIDO2 security keys, Microsoft Authenticator app, Windows Hello for Business, Temporary Access Pass for onboarding), Conditional Access (policy-based access control evaluating risk signals including user risk, sign-in risk, device compliance, location, application sensitivity before granting or blocking access), Identity Protection (machine learning-based risk detection identifying compromised accounts, suspicious sign-in patterns, anonymous IP usage, unfamiliar locations, malware-linked IP addresses, leaked credentials from Microsoft threat intelligence), Privileged Identity Management (just-in-time privileged access for administrative roles, approval workflows, time-limited role assignments, activation alerts, access reviews for privileged roles), Application Management (app registrations, enterprise applications gallery, OAuth 2.0 authorization server, API permissions management, consent framework for delegated and application permissions), User and Group Management (user provisioning and deprovisioning, dynamic groups with membership rules, organizational unit structure, bulk user operations, self-service group management), Device Management Integration (Azure AD Join, Hybrid Azure AD Join, device registration, device compliance integration with Microsoft Intune), B2B Collaboration (inviting external users from partner organizations with guest access, cross-tenant access policies, external user lifecycle management), Entra External ID for Customer Identity (self-service registration and sign-in for consumer-facing applications with social identity providers, custom authentication flows via User Flows and Custom Policies in Azure AD B2C, passkeys, branded login experiences, user attribute collection), Identity Governance (access reviews for certifying user access, entitlement management for automated access package management, lifecycle workflows automating joiner-mover-leaver processes), and Workload Identities (managed identities for Azure resources enabling passwordless service authentication, service principals for application identity, federated identity credentials for external workload authentication).

The data controller-processor relationship according to DPA (May 2026) establishes distinctions across three defined data categories. For Customer Data (data customers provide or generate via Microsoft services including authentication events, user profiles, directory entries, configuration data, application registrations, sign-in logs), Microsoft acts as processor processing per customer instructions documented in agreement. For Personal Data (subset of Customer Data identifying individuals and data Microsoft collects about individuals in commercial relationships such as billing contacts), Microsoft acts as processor for data within services and controller for data in commercial relationships. For Professional Services Data (data provided during support engagements including diagnostic logs, system information, problem descriptions), Microsoft acts as processor.

According to DPA explicit commitments, Microsoft processes data from these categories to provide products and services per customers' documented instructions and for business operations—not for user profiling, advertising, or market research. Microsoft prohibits using Customer Data in testing environments. Microsoft pseudonymizes and aggregates diagnostic data to protect confidentiality. Microsoft uses data isolation techniques separating cloud tenants ensuring customers access only their own data.

According to infrastructure scale, Microsoft operates cloud infrastructure across 60+ Azure regions globally with data centers owned and operated by Microsoft representing one of world's largest infrastructure investments. For US government, Microsoft Azure Government and Azure Government Secret provide isolated clouds with additional access controls meeting DoD and intelligence community requirements.

Pricing structure includes Entra ID Free (included with Microsoft cloud services and Azure subscription—core authentication, SSO for up to 10 apps, user and group management, cloud user provisioning, self-service password reset for cloud users, Basic security reports, Microsoft Authenticator app), Entra ID P1 ($6 per user/month—includes Free plus hybrid identity, Conditional Access, cloud and on-premise app provisioning with SCIM, self-service password reset for hybrid environments, Microsoft Entra Connect for hybrid, advanced security reports, Identity Protection basic alerts), Entra ID P2 ($9 per user/month—includes P1 plus Identity Protection with risk-based Conditional Access, Privileged Identity Management, access reviews, entitlement management), and Entra ID Governance (additional advanced lifecycle and access governance capabilities beyond P2). Entra External ID for customer-facing applications priced separately per MAU with free tier up to 50,000 MAU monthly.

Microsoft Entra ID data collection framework follows DPA three-category structure distinguishing Customer Data (data Microsoft processes as processor for customer's identity service), Personal Data (individually-identified subset), and Professional Services Data (support engagement data). According to DPA (May 2026), Privacy Policy, and EU Data Boundary documentation, following data categories apply.

Customer Data (Processor Role): For data organizations provide to Microsoft or generate via Entra ID services, Microsoft acts as processor. Customer Data includes end-user identity records (display names, user principal names typically formatted as email addresses, email addresses, job titles, department names, office locations, phone numbers, manager relationships, employee IDs, custom extension attributes configured by tenant administrator, profile photos, account type designations), authentication credentials (password hashes for hybrid environments synchronized from on-premise Active Directory using irreversible hash function ensuring Microsoft cannot recover plaintext passwords, FIDO2 public keys for passwordless authentication where private keys never leave user device, certificate thumbprints for certificate-based authentication, Temporary Access Pass tokens for onboarding), authentication event logs (sign-in timestamps, IP addresses, geolocation derived from IP, device identifiers, browser and application used, authentication method, Conditional Access policy evaluation results, success or failure status, multi-factor authentication challenge type and result, risk level assessed by Identity Protection), device registration records (device name, operating system and version, device identifier, device compliance status from Intune, hybrid join status, last sign-in time), application registrations (client IDs, permitted redirect URIs, OAuth scopes defined, API permission grants, client secret metadata without secret values), enterprise application assignments (which users and groups assigned to which applications, access packages, entitlement policies), group memberships (security group and Microsoft 365 group memberships, dynamic group membership rule results, Privileged Identity Management role eligibility and assignment history), and audit logs (administrative actions taken by tenant admins, permission grant events, risk event detections and dismissals, policy changes, user creation and deletion events).

External ID Customer Data: For organizations using Entra External ID for consumer-facing applications, Customer Data additionally includes external user registration data (email, social provider identifier from Google/Facebook/Apple/etc., custom attributes defined in user flow), consumer authentication events (registration, sign-in, password reset, profile update), custom policy execution data (results of custom authentication logic defined in Azure AD B2C Custom Policies or Entra External ID User Flows), and consumer session tokens.

Microsoft Threat Intelligence Data: For Identity Protection risk detection, Microsoft processes risk signal data aggregating anonymized threat intelligence across Microsoft customer base to generate risk scores. This involves Microsoft accessing certain anonymized patterns from across tenants (never sharing individual tenant's identity data with other tenants) to identify IP addresses associated with credential stuffing, known attacker infrastructure, leaked credential matching against Microsoft's breach intelligence database, and behavioral anomalies. Fraud signal IP addresses and phone numbers determined to be used in fraudulent activities published globally by Microsoft across all Entra ID deployments for protective purposes—this specific egress occurs even in EU Data Boundary configurations as this transfer is by design to facilitate service security function.

Professional Services Data: During support interactions, Microsoft processes problem descriptions and reproduction steps provided by customers, system diagnostic information including sign-in logs and configuration exports, screenshots or recordings of issues, and any personal data within support materials provided by customer. Microsoft commits to not using Professional Services Data for sales or marketing purposes.

Microsoft Operational Data (Controller Role): For operating Entra ID service, Microsoft processes as controller infrastructure telemetry (service health metrics, performance counters, error rates, capacity utilization—not linked to individual customer data), security operations data (threat intelligence aggregated across global deployment for improving threat detection models), product improvement signals (feature usage patterns aggregated and anonymized for informing Entra ID roadmap), and billing and commercial relationship data (subscription details, license assignments, payment information, contact data for billing communications).

Data Microsoft Entra ID Does NOT Collect: According to DPA explicit commitments and service architecture, Microsoft does not use Customer Data for advertising, user profiling, or market research, does not make Customer Data available to other Microsoft customers or use for testing purposes, does not access end-user application content within applications secured by Entra ID (Entra ID controls access to applications but does not read application data within those applications), does not share raw Customer Data across tenants for threat intelligence purposes (only anonymized signals aggregated), and does not sell personal data per Microsoft privacy commitments.

Microsoft Entra ID legal basis for processing personal data varies depending on whether Microsoft acts as processor (for Customer Data per DPA) or controller (for operational and commercial data), and differs by jurisdiction. According to DPA (May 2026), Microsoft Privacy Statement, and GDPR compliance documentation, following legal bases apply.

Contractual Necessity for Processor Role: When organizations subscribe to Entra ID, Microsoft acts as processor for Customer Data per DPA. DPA establishes Microsoft processes Customer Data to provide online services per customer's documented instructions in Master Subscription Agreement and DPA. Contractual necessity justifies processing authentication events, maintaining user directory, issuing tokens, enforcing Conditional Access policies, operating Identity Protection, managing privileged access via PIM, and all functions required to deliver contracted Entra ID services per subscription agreement.

Customer's Legal Basis Responsibility: While Microsoft as processor relies on contractual necessity with customers, customers as controllers bear responsibility for establishing appropriate legal bases for collecting and processing end-user identity data. According to GDPR Article 6 framework, organizations typically rely on contractual necessity (where authentication required to provide employment services or digital services end-users contracted for), legitimate interests (where workforce identity management serves legitimate organizational security and operational purposes not overriding employee rights—workforce IAM generally accepted as legitimate interest basis), or legal obligation (where authentication and access logging required by applicable law for compliance or security mandates). For EU customers relying on legitimate interests, appropriate balancing tests should be conducted and documented.

Customers responsible for providing privacy notices to employees and external users explaining Microsoft Entra ID processing, obtaining any required consents for optional processing beyond core authentication function, implementing data subject rights fulfillment using Entra ID administrative tools and Microsoft Graph API, conducting Data Protection Impact Assessments for high-risk identity processing, and maintaining Records of Processing Activities per GDPR Article 30 documenting Entra ID as processor.

Microsoft as Controller - Contractual Necessity and Legitimate Interests: For operational data and commercial relationship data, Microsoft as controller processes based on contractual necessity (providing Entra ID service, billing, account management) and legitimate interests (service reliability monitoring, security operations, threat intelligence for improving protection across Microsoft customer base, product improvement through aggregated and anonymized usage analytics). Microsoft Privacy Statement describes these controller-capacity processing activities.

CLOUD Act and Legal Process Compliance: Critical consideration per DPA and Microsoft Government Data Requests policy—DPA explicitly states Microsoft may comply with valid legal process (subpoenas, court orders, warrants under US CLOUD Act or domestic laws of other jurisdictions) even if this conflicts with customer's instructions as controller. Microsoft commits to notifying customers of government requests for Customer Data unless legally prohibited from doing so (gag orders frequently accompany CLOUD Act warrants preventing notification). Microsoft will provide copy of demand unless legally prohibited. Microsoft challenges overbroad or otherwise improper government demands. Microsoft publishes Law Enforcement Requests Reports documenting government request volumes by country.

This CLOUD Act exposure is material compliance consideration particularly for EU organizations—even with EU Data Boundary configuration confining data to EU data centers, US CLOUD Act warrants can compel Microsoft to produce EU-resident data held in EU data centers under CLOUD Act's extraterritorial jurisdiction over US companies. EU organizations should document this risk in Transfer Impact Assessments per EDPB Schrems II guidance and implement supplementary measures where possible (though CLOUD Act exposure applies to US-company providers regardless of data location).

EU-US Data Privacy Framework: According to Microsoft privacy documentation, Microsoft certified under EU-US Data Privacy Framework providing adequacy under GDPR Article 45 for transfers to certified Microsoft entities in United States. DPF certification supplements SCCs as transfer mechanism.

Standard Contractual Clauses: According to DPA, SCCs (2021 revision, Decision 2021/914) incorporated in DPA for international transfers of EU/EEA/UK Personal Data to Microsoft in United States and to Microsoft subprocessors in third countries. SCCs address processing instructions, security measures, subprocessor engagement, data subject rights assistance, breach notification, and audit provisions. Customers should verify DPA version ensuring 2021 SCCs rather than older 2010 SCCs which no longer valid per European Commission decision.

CCPA/CPRA Service Provider: Under California law, Microsoft acts as service provider for Personal Information processed in Customer Data context, subject to CCPA service provider restrictions prohibiting selling, sharing, or using personal information outside direct business relationship. Microsoft's DPA addresses US Privacy Laws prohibiting sale or sharing of Personal Data as defined under applicable US state laws.

Compliance with Legal Obligations and Security Operations: According to DPA, Microsoft may process data to comply with applicable laws, respond to valid legal process from courts and regulators, fulfill mandatory security disclosure obligations, and maintain audit records required by applicable compliance frameworks.

Microsoft maintains publicly accessible Online Services Subprocessors List at Microsoft Trust Center identifying subprocessors authorized to process Customer Data or Personal Data. According to data residency and subprocessor documentation, Microsoft engages subprocessors for specific service delivery functions with customer notification before adding new subprocessors and termination-without-penalty right for customer objections.

Subprocessor Transparency Framework: According to Microsoft Data Residency documentation, Microsoft Online Services Subprocessors List identifies all subprocessors authorized to process customer data or personal data with contractual obligations to meet or exceed Microsoft's commitments to customers. Microsoft will not provide subprocessors direct, blanket, or unfettered access to customers' data, platform encryption keys or ability to break encryption, or access if Microsoft aware data to be used for purposes other than stated in request.

According to notification policy, for new subprocessors for new online services, Microsoft notifies customers before making service available to them. If customer does not accept new subprocessor, customer may terminate subscription without penalty with written notice. This termination-without-penalty right provides stronger customer protection than typical 10-30 day objection windows in comparable enterprise SaaS DPAs.

Microsoft Affiliate Entities: Primary subprocessors for Entra ID include Microsoft corporate entities including Microsoft Ireland Operations Limited (serving as EU data controller for EU customers, processing authentication requests, operating EU Data Boundary data centers), Microsoft regional subsidiaries (Singapore, Japan, Australia, India, Canada, and other regional entities providing local operations and support), Microsoft Corporation (US parent entity), and LinkedIn Corporation (subsidiary, relevant for LinkedIn integration features where enabled).

Infrastructure Partners: Microsoft operates primarily on Microsoft-owned and managed data center infrastructure distinguishing it from providers relying on third-party cloud (AWS or GCP). However, specific infrastructure components and technical subprocessors supporting Entra ID listed in Microsoft Trust Center subprocessor documentation. Customers should access current subprocessor list at Microsoft Trust Center as this profile reflects publicly available information at time of writing.

Communication Services for MFA: For SMS and voice-based multi-factor authentication delivery, Microsoft engages telecommunications carriers and communication platform providers to deliver verification codes to user phone numbers globally. Specific carrier and CPAA subprocessors vary by region and are documented in subprocessor list. These providers process phone numbers and OTP message content as subprocessors for authentication delivery.

Security and Threat Intelligence: Microsoft operates global threat intelligence infrastructure incorporating signals from across Microsoft customer base (anonymized and aggregated) to power Identity Protection risk detection. This operates within Microsoft entity structure rather than requiring third-party subprocessors for core threat intelligence, though specific security service subprocessors may be documented in Trust Center.

Support and Customer Success Operations: For delivering customer support and professional services, Microsoft may engage subprocessors including customer service platform providers, ticketing and case management systems, and regional support delivery partners. Support interactions may involve Professional Services Data transfer to subprocessors under appropriate contractual protections.

How to Access Current Subprocessors: Current complete subprocessor list available at Microsoft Trust Center (servicetrust.microsoft.com) under Privacy documentation section. List updated as subprocessors change with customer notification as described above. Developers should access live Trust Center documentation rather than relying on this static profile for vendor risk assessment purposes.

Microsoft Entra ID international data transfer framework combines EU Data Boundary program for EU data residency, EU-US Data Privacy Framework certification, and Standard Contractual Clauses providing layered compliance. According to EU Data Boundary documentation, DPA (May 2026), and Microsoft data residency documentation, following framework applies.

EU Data Boundary Program: According to EU Data Boundary documentation (finalized 2025), Microsoft created EU Data Boundary enabling organizations with EU/EFTA billing addresses to store and process Customer Data and pseudonymized personal data in data centers located in EU or EFTA countries. Microsoft Entra ID enrolled in EU Data Boundary program with following nuances.

For organizations within EU Data Boundary scope, Entra ID stores and processes primary directory data, authentication events, sign-in logs, and configuration data within EU/EFTA data centers. Microsoft Ireland Operations Limited operates as data controller for EU customers under Microsoft corporation umbrella. EU Data Boundary covers standard Entra ID operations for enrolled customers.

Documented EU Data Boundary Exceptions for Entra ID: According to official Microsoft Entra EU data storage documentation, certain Entra ID data transfers outside EU Data Boundary occur by design or temporarily. Permanent design exceptions include fraud signal global publication—when IP addresses or phone numbers determined to be used in fraudulent activities, they are published globally across all Entra ID deployments to block access from any workloads using them, requiring this specific data to exit EU boundary for global fraud prevention function. Temporary exception under remediation includes Directory Core Store—some tenants initially created with non-European country code later changed to European country code may have user and device account data and service configuration (application, policy, and group) stored in US and Asia/Pacific locations pending migration to EU; Microsoft documents this as temporary with remediation in progress. Multitenant collaboration exception—administrator configuration and use of multitenant collaboration with tenants outside EU Data Boundary may result in some customer data (user and device account data, usage data, service configuration) being stored and processed in location of collaborating tenant outside EU boundary.

CLOUD Act Extraterritorial Jurisdiction: Critical consideration for EU organizations regardless of EU Data Boundary configuration—US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) asserts US government authority to compel US companies including Microsoft to produce customer data held anywhere in world including EU data centers. This means even data stored exclusively in EU Data Boundary data centers remains subject to potential US government access under CLOUD Act warrants. Microsoft commits to challenging overbroad demands and notifying customers unless legally prohibited. EU organizations should assess CLOUD Act exposure in Transfer Impact Assessments as separate from data residency—confining data to EU data centers does not eliminate CLOUD Act exposure for US-entity providers.

Standard Contractual Clauses (2021 Revision): According to DPA, SCCs under Decision 2021/914 incorporated for transfers of EU/EEA/UK Personal Data from EU to Microsoft in US and to subprocessors in third countries. SCCs serve as primary Article 46 safeguard for transfers. Organizations should verify their DPA incorporates 2021 SCCs rather than legacy 2010 SCCs now invalid per European Commission decision.

EU-US Data Privacy Framework: Microsoft certified under EU-US Data Privacy Framework providing adequacy under GDPR Article 45 for transfers to certified Microsoft entities in US. DPF supplements SCCs providing additional transfer basis. Note that DPF adequacy could be challenged before European courts as Privacy Shield predecessor was invalidated—organizations with strict transfer requirements should maintain SCC documentation as independent safeguard.

Azure Regions for Data Residency: According to Azure data residency documentation, Microsoft operates 60+ Azure regions globally including dedicated EU regions (West Europe in Netherlands, North Europe in Ireland, UK South in London, UK West in Wales, France Central, France South, Germany West Central, Germany North, Sweden Central, Sweden South, Norway East, Norway West, Switzerland North, Switzerland West, Poland Central, Italy North, Spain Central, and others) enabling regional data residency selection. For Azure services (which underpin Entra ID infrastructure), customers selecting EU regions receive data residency commitments for Customer Data in selected region.

Government Cloud for US Federal: For US federal agencies and defense, Microsoft Azure Government (US-only sovereign cloud with FedRAMP High authorization, DoD Impact Level authorizations) provides isolated infrastructure with restricted personnel access limited to US persons. Microsoft Entra External ID holds FedRAMP High authorization enabling US government customer identity deployments. Azure Government Secret and Top Secret clouds provide additional isolation for classified workloads.

Microsoft's Government Data Access Commitments: According to Microsoft Data Residency documentation and contractual commitments, Microsoft commits to not providing third parties direct, blanket, or unfettered access to customers' data; directing government requesting parties to seek data directly from customer; promptly notifying customer of government demands and providing copy unless legally prohibited; vigorously challenging unlawful government demands; limiting access to only what legally required; and publishing Law Enforcement Request Reports documenting government request volumes by country and request type.

When developers integrate Microsoft Entra ID (via Entra External ID for customer-facing apps, or Entra ID for workforce authentication in SaaS products) they assume extensive compliance responsibilities as data controllers. According to controller-processor distinction, DPA obligations, and data protection principles, following developer responsibilities apply.

Understanding Controller Role: Developers integrating Entra External ID for consumer-facing authentication or configuring Entra ID for employee or B2B authentication are data controllers for identity data processed through Microsoft's platform. Microsoft as processor executes developer/customer instructions. Developers bear primary legal responsibility for GDPR, CCPA, and applicable privacy law compliance including establishing lawful bases, providing privacy notices, implementing data subject rights, and ensuring appropriate processing.

Privacy Policy Requirements: Developers must maintain comprehensive privacy policies covering Microsoft Entra processing including identifying Microsoft (Entra ID) as identity processor, disclosing what identity data collected (email addresses, display names, social provider identifiers, authentication history, device identifiers), explaining how data used (authentication, account management, security monitoring, access logging), detailing data retention periods (active account duration, sign-in log retention which developers can configure and should set appropriately per GDPR Article 5 storage limitation—Microsoft documentation suggests setting to 30 days maximum where technically feasible), addressing international transfers (EU Data Boundary enrollment status, SCCs, CLOUD Act exposure where relevant), explaining user rights (access, deletion, rectification, portability, objection), providing privacy contact information, and referencing applicable laws (GDPR for EU users, CCPA for California users, etc.).

Implementing Data Subject Rights via Microsoft Graph API: Under GDPR and CCPA, end-users have rights developers must fulfill using Microsoft Graph API and Entra admin center including access (retrieve user profile and authentication history via GET /users/{id} and sign-in logs from Microsoft Entra admin center or Graph API), deletion (delete user account via DELETE /users/{id} removing directory entry, authentication credentials, group memberships—sign-in logs may persist per retention settings, administrators should configure and monitor retention), rectification (update user profile via PATCH /users/{id}), portability (export user data via Microsoft Entra admin center data export functionality or Graph API), objection (disable account or restrict processing for objecting users), and restrict processing (suspend account pending dispute resolution).

Developers must implement user-facing request mechanisms, verify requester identity securely, execute rights requests via Microsoft Graph API or admin tools, document fulfillment actions and timestamps, and respond within regulatory timeframes (30 days GDPR, 45 days CCPA with possible extension).

EU Data Boundary Configuration: EU-based developers or those serving EU end-users should verify EU Data Boundary enrollment ensuring tenant provisioned in EU/EFTA region. For Microsoft 365 customers, sign-up location in EU/EFTA country determines EU Data Boundary scope. For Azure-based deployments, selecting EU Azure regions ensures in-scope data residency. Developers should document EU Data Boundary enrollment status in DPIA and ROPA as EU data residency measure.

However, developers must also document and communicate EU Data Boundary limitations including fraud signal egress, multitenant collaboration exceptions, and CLOUD Act extraterritorial exposure in privacy documentation and TIAs. EU Data Boundary does not provide complete isolation from US jurisdiction.

Transfer Impact Assessment for EU Data: Developers in EU or processing EU personal data should complete Transfer Impact Assessment evaluating risks of Microsoft Entra ID processing including US jurisdiction over Microsoft Corporation creating CLOUD Act exposure, SCCs and EU Data Boundary as implemented safeguards, Microsoft's government data request policies and transparency reports as supplementary measures, technical measures (encryption, access controls, pseudonymization), and residual risk assessment determining whether implemented safeguards provide essentially equivalent protection. EDPB Recommendation 01/2020 provides TIA methodology. CLOUD Act exposure should be explicitly addressed—TIA cannot eliminate CLOUD Act risk but should document it with implemented mitigations.

Sign-In Log Retention Configuration: Developers should configure appropriate sign-in log retention periods balancing security monitoring needs against GDPR Article 5 storage limitation principle. Microsoft Entra ID sign-in logs default retention varies by license tier (7 days for free tier, 30 days for P1/P2). Developers should stream logs to dedicated storage (Azure Monitor, SIEM) for longer retention where required for security or compliance while implementing appropriate access controls and retention policies in log destination. Per GDPR storage limitation, retain only as long as necessary for specified purposes.

Conditional Access Policy Implementation: Developers integrating Entra ID into SaaS products should implement appropriate Conditional Access policies protecting customer access including requiring MFA for privileged operations, blocking risky sign-in attempts via Identity Protection risk levels, restricting access from non-compliant devices where appropriate for security posture, applying location-based restrictions for regulated data access, and monitoring Conditional Access policy effectiveness via sign-in logs and workbooks.

Entra External ID User Flows and Custom Policies: For customer identity deployments using Entra External ID, developers responsible for configuring appropriate user flows and custom policies including collecting only necessary user attributes during registration (data minimization—avoid collecting attributes not needed for application function), implementing consent collection where required (GDPR-compliant consent for optional data processing, age verification for services directed at children), providing branded and accessible authentication experiences, implementing email verification for self-registered accounts, configuring appropriate social identity provider connections (collecting minimum scopes from social providers), and testing authentication flows for accessibility and compliance.

Privileged Access and Principle of Least Privilege: Developers granting Entra ID permissions to applications responsible for following least privilege principles including requesting only OAuth scopes actually required for application function, distinguishing delegated permissions (user-context access limited by user's own access) from application permissions (service-level access requiring higher justification), implementing Privileged Identity Management for administrative access to Entra ID tenant, regularly reviewing application permission grants via access reviews, rotating client secrets per organizational policies, and monitoring for permission scope creep over time.

Monitoring and Incident Response: Developers should implement monitoring for security incidents via Entra ID logs including streaming sign-in logs and audit logs to SIEM for centralized monitoring, enabling Identity Protection risk detections for high-risk sign-in alerting, configuring Conditional Access alerts for policy failures, establishing incident response procedures for identity compromise, notifying affected users of account security events, reporting data breaches to supervisory authorities per GDPR 72-hour requirement and applicable US state breach notification laws, and documenting incidents for regulatory examination.

Core Documentation:

Trust and Compliance: