Dynamic Conditional Access Policies
with Custom Security Attributes

Table of Contents

1. Introduction to Dynamic Conditional Access Policies

1.1 Executive Overview

Modern enterprises face a critical inflection point in identity and access management. The traditional approach of creating individual Conditional Access Policies for each application has become untenable as organizations scale their cloud footprint. A typical Fortune 500 company with 1,000+ cloud applications would need to manage an equivalent number of policies, each with unique security requirements, exceptions, and maintenance overhead.

The challenge of policy sprawl in modern enterprises manifests in several ways:

• Administrative Complexity: Managing hundreds or thousands of individual policies requires significant resources and expertise
• Increased Risk: More policies mean more opportunities for misconfiguration and security gaps
• Reduced Agility: Adding new applications or changing security requirements requires creating or modifying multiple policies
• Inconsistent Security: Similar applications may have different security controls due to policy drift over time
• Testing Overhead: Validating hundreds of policies becomes a bottleneck for security improvements

Dynamic Conditional Access Policies with Custom Security Attributes solve these challenges by introducing a new paradigm: instead of creating policies for applications, we create policies for security requirements and tag applications with those requirements.

1.2 What is a Dynamic Conditional Access Policy?

A Dynamic Conditional Access Policy is a Conditional Access Policy that uses application filters based on Custom Security Attributes to dynamically determine which applications are in scope. Rather than explicitly listing applications in the policy, the policy uses intelligent filtering to automatically include or exclude applications based on their assigned security attributes.

Traditional Static CAP Approach:

• Policy 1: "SharePoint Online - Require MFA + Compliant Device"
• Policy 2: "Exchange Online - Require MFA + Compliant Device"
• Policy 3: "Teams - Require MFA + Compliant Device"
• Policy 4: "Power BI - Require MFA + Compliant Device"
• Policy 5: "Dynamics 365 - Require MFA + Compliant Device"

Result: 5 policies for 5 applications, all with identical security requirements

Dynamic CAP Approach:

• Attribute: SecurityLevel = "Standard" (assigned to all 5 applications)
• Policy 1: "Applications with SecurityLevel=Standard - Require MFA + Compliant Device"

Result: 1 policy covering 5 applications through intelligent attribute matching

Aspect	Static CAPs	Dynamic CAPs
Policy Count	1 policy per application	1 policy per security requirement
Application Targeting	Explicit application selection	Attribute-based filtering
New Application Onboarding	Create new policy or modify existing	Assign appropriate attributes
Maintenance Overhead	High - manage N policies	Low - manage attributes + few policies
Consistency	Manual effort required	Automatic through attribute taxonomy
Exception Management	Complex - requires policy modification	Simple - change attribute assignment
Audit and Compliance	Application-specific evidence	Attribute-based compliance mapping
Testing Requirements	Test every policy change	Test attribute assignment changes

1.3 Understanding Custom Security Attributes

Custom Security Attributes in Microsoft Entra ID provide a powerful framework for extending directory objects with business-specific metadata. Unlike traditional directory extensions, Custom Security Attributes are designed specifically for security and governance scenarios, offering enhanced access control and audit capabilities.

Key Concepts

Attribute Sets: Logical containers that group related attributes together. Each attribute set can contain up to 500 attributes and can be managed independently.

Attribute Definitions: The schema definition of an attribute, including its name, data type, allowed values, and business description.

Attribute Assignments: The actual values assigned to directory objects (users or service principals).

Data Types and Use Cases

Data Type	Description	Use Cases	Example Values
Boolean	True/False values	Feature flags, compliance requirements	true, false
Integer	Numeric values	Risk scores, priority levels	1, 2, 3, 100
String	Text values (single or multiple)	Security levels, geographical regions	"Standard", "US", "Finance"

Attribute Properties and Lifecycle

Property	Description	Can Change Later?
Attribute Set Name	Container for related attributes	No
Attribute Name	Unique identifier within set	No
Data Type	Boolean, Integer, or String	No
Allow Multiple Values	Single or multi-value assignment	No
Predefined Values Only	Restrict to specific values	Yes (No→Yes only)
Predefined Values List	Allowed values when restricted	Yes
Attribute Active Status	Enable/disable attribute	Yes

1.4 The Evolution of Conditional Access

The Policy Explosion Problem

Year	Applications	Policies	Management Overhead	Primary Challenges
2018	10	10	Low	Learning curve
2020	50	75	Medium	Policy standardization
2022	200	350	High	Exception management
2024	500	800+	Critical	Scalability crisis

The Shift to Dynamic, Attribute-Based Policies

Traditional Model	Dynamic Model	Improvement
Reactive policy creation	Proactive attribute taxonomy	Predictable governance
Application-specific security	Risk-based security levels	Consistent protection
Manual policy management	Automated attribute assignment	Operational efficiency
Siloed security decisions	Centralized security taxonomy	Strategic alignment
Point-in-time compliance	Continuous compliance monitoring	Regulatory readiness

1.5 Technical Architecture Overview

Integration Points

Integration Point	Purpose	Frequency
Microsoft Graph API	Attribute management and queries	Real-time
Azure Monitor	Logging and alerting	Near real-time
Microsoft Sentinel	Security monitoring and SIEM	Near real-time
PowerShell/CLI	Automation and management	On-demand
Third-party SIEM	Security monitoring	Configurable

2. Why Dynamic CAPs Are Used

2.1 Business Drivers

• Application Portfolio Growth: Enterprises are adding 15-20% more cloud applications annually
• Multi-Cloud Strategies: Organizations use an average of 2.6 public clouds, each with different security models
• Zero Trust Principles: Never trust, always verify with context-aware access controls
• Regulatory Compliance: GDPR, HIPAA, PCI-DSS, and FedRAMP have unique access control requirements
• DevOps Integration: Security controls must integrate seamlessly with CI/CD pipelines

2.2 Challenges with Traditional CAPs

Policy Sprawl: The Mathematical Reality

Applications	Base Policies	Exception Policies	Compliance Policies	Total Policies	Mgmt Hours/Month
10	10	3	2	15	5
50	50	15	10	75	25
200	200	60	40	300	100
500	500	150	100	750	250
1000	1000	300	200	1500	500+

2.3 Benefits of Dynamic CAPs

Scenario	Traditional Policies	Dynamic Policies	Reduction	Time Savings
Small Enterprise (50 apps)	75	12	84%	20 hours/month
Mid Enterprise (200 apps)	300	18	94%	80 hours/month
Large Enterprise (500 apps)	750	25	97%	200 hours/month
Enterprise (1000 apps)	1500	35	98%	400 hours/month

Application Onboarding Time Comparison

Activity	Traditional Approach	Dynamic CAP Approach	Time Savings
Security Assessment	2-4 hours	30 minutes	2-3.5 hours
Policy Creation	1-2 hours	5 minutes	1-2 hours
Testing	4-8 hours	30 minutes	3.5-7.5 hours
Documentation	1 hour	10 minutes	50 minutes
Approval Process	24-48 hours	2-4 hours	20-44 hours
Total	32-62 hours	3-5 hours	27-57 hours

2.4 Enterprise Use Cases

Scenario	Industry	Traditional Approach	Dynamic Approach	Benefits
High-Value Financial Applications	Financial Services	25 individual policies for trading platforms	1 policy targeting SecurityLevel="Maximum"	96% policy reduction
Healthcare Data Access	Healthcare	40 policies for EMR systems	2 policies (HIPAA + Geographic attributes)	95% reduction
Executive Protection	All Industries	15 policies for executive apps	1 policy for ExecutiveAccess="Required"	93% reduction
PCI-DSS Compliance	Retail	25 policies for payment applications	1 policy for PCIScope="InScope"	96% reduction

2.5 Quantifiable Impact

Metric	Before Dynamic CAPs	After Dynamic CAPs	Improvement
Number of Conditional Access Policies	150-500+	15-30	70-95% reduction
Time to Onboard New Application	2-4 hours	10-15 minutes	85-90% faster
Policy Management Effort (hours/month)	80-120 hours	20-30 hours	70-75% reduction
Configuration Errors per Quarter	10-15	1-3	80-90% reduction
Time to Implement Security Changes	1-2 weeks	1-2 days	80-90% faster

3. How Dynamic CAPs Are Used

3.1 Technical Architecture Deep Dive

When a user attempts to access an application, the following sequence occurs:

1. Authentication Request: User initiates sign-in to an application
2. Service Principal Identification: Entra ID identifies the target service principal
3. Attribute Retrieval: System loads all custom security attributes assigned to the service principal
4. Baseline Policy Evaluation: Persona-based baseline policies are evaluated first (ALL RESOURCES scope)
5. Dynamic Policy Matching: Application filters in dynamic CAPs are evaluated against the service principal's attributes
6. Policy Aggregation: All matching policies (baseline + dynamic) are combined
7. Control Application: The strictest required controls are applied
8. Access Decision: Access is granted or blocked based on whether all controls are satisfied
9. Session Establishment: If granted, session controls from all matching policies are applied

3.2 Custom Security Attributes as Metadata Tags

Attribute Assignment Mechanisms

Method	Use Case	Advantages	Considerations
Azure Portal (Entra Admin Center)	Individual application tagging, initial setup	Visual interface, easy to learn	Manual process, not suitable for bulk operations
Microsoft Graph API	Automated workflows, integration with CMDB	Programmatic control, integration capabilities	Requires development expertise
PowerShell (Graph SDK)	Bulk operations, scripted management	Automation, reusable scripts, audit trails	Requires PowerShell expertise
Azure CLI	Command-line automation, CI/CD pipelines	Cross-platform, simple syntax	Limited compared to PowerShell/Graph API

Graph API Query Examples

// 1. Find all apps with specific security level
GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=customSecurityAttributes/ContosoSecurity/SecurityLevel eq 'Maximum'

// 2. Find apps with multiple attribute conditions
GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=customSecurityAttributes/ContosoSecurity/SecurityLevel eq 'Enhanced' and customSecurityAttributes/ContosoCompliance/HIPAAScope eq true

// 3. Select specific attributes in response
GET https://graph.microsoft.com/v1.0/servicePrincipals?$select=displayName,customSecurityAttributes

3.3 Application Filter Mechanism

Supported Operators

Operator	Description	Example
-eq	Equals (exact match)	SecurityLevel -eq "Maximum"
-ne	Not equals	Environment -ne "Production"
-in	Value in list	Region -in ["US", "EU", "APAC"]
-contains	Contains substring	Department -contains "Finance"
-startsWith	Starts with string	AppName -startsWith "Contoso"

Complex Filter Examples

// Single attribute match
application.extension_abc123_SecurityLevel -eq "Enhanced"

// Multiple attributes with AND logic
application.extension_abc123_SecurityLevel -eq "Maximum" -and 
application.extension_abc123_ComplianceFramework -eq "HIPAA"

// Multiple attributes with OR logic
application.extension_abc123_DataClassification -eq "PHI" -or 
application.extension_abc123_DataClassification -eq "PII"

// Combining AND/OR
(application.extension_abc123_SecurityLevel -eq "Enhanced" -or 
 application.extension_abc123_SecurityLevel -eq "Maximum") -and
application.extension_abc123_NetworkRequirement -eq "TrustedOnly"

3.4 Implementation Approach 1: Aggregated Controls

Security Level	Authentication	Device	Network	Session Controls
Level 1: Standard	MFA Required	Compliant or Hybrid Joined	Any location	Token lifetime: 12 hours
Level 2: Enhanced	Passkeys or Passwordless	Compliant Device Required	Corporate network or VPN	Token lifetime: 4 hours
Level 3: Maximum	Phishing-resistant MFA	Compliant Device Required	Trusted locations only	Token lifetime: 1 hour, No downloads

PowerShell: Create Attribute Set and Assign to Applications

Connect-MgGraph -Scopes "CustomSecAttributeDefinition.ReadWrite.All"

# Create attribute set
$attributeSet = @{
    Id = "ContosoSecurity"
    Description = "Contoso security level attributes for dynamic CAPs"
    MaxAttributesPerSet = 25
}
New-MgDirectoryAttributeSet -BodyParameter $attributeSet

# Create SecurityLevel attribute
$attribute = @{
    AttributeSet = "ContosoSecurity"
    Name = "SecurityLevel"
    Type = "String"
    UsePreDefinedValuesOnly = $true
    AllowedValues = @(
        @{ Id = "Standard"; IsActive = $true }
        @{ Id = "Enhanced"; IsActive = $true }
        @{ Id = "Maximum"; IsActive = $true }
    )
}
New-MgDirectoryCustomSecurityAttributeDefinition -BodyParameter $attribute

3.5 Implementation Approach 2: Fine-Grained Attributes

The Fine-Grained Attributes approach treats each security dimension as a separate attribute, allowing applications to have precisely tailored security controls.

Attribute Category	Attribute Name	Data Type	Possible Values
Authentication	AuthenticationStrength	String	MFA, Passwordless, PhishingResistant
	AllowSMSMFA	Boolean	true, false
Device Requirements	DeviceCompliance	String	Required, Preferred, NotRequired
	AllowBYOD	Boolean	true, false
Network	NetworkRequirement	String	Any, Corporate, TrustedOnly
	BlockHighRiskCountries	Boolean	true, false
Session Controls	TokenLifetime	String	1h, 4h, 8h, 12h, 24h
	SessionType	String	Standard, Restricted, Privileged
Data Protection	AllowDownload	Boolean	true, false
	AllowPrint	Boolean	true, false
	AllowCopyPaste	Boolean	true, false

3.6 Approach Comparison and Selection

Decision Factor	Choose Aggregated	Choose Fine-Grained
Team Experience	New to Dynamic CAPs	Experienced with Conditional Access
Application Portfolio	Mostly standard business apps	Diverse with unique requirements
Governance Model	Centralized control	Delegated to application owners
Time to Implement	Need quick wins (2-4 weeks)	Can invest time (6-12 weeks)
Compliance Needs	Standard frameworks	Multiple complex frameworks

3.7 Integration with Baseline Persona-Based CAPs

4. What Dynamic CAPs Are Used For

4.1 Enhanced Security Requirements

Token Lifetime Management

• Standard (12 hours): General business applications
• Sensitive (4 hours): Applications with customer data
• Critical (1 hour): Financial systems, privileged access

Authentication Strength Requirements

• MFA: Any multi-factor method (SMS, app, hardware token)
• Passwordless: Windows Hello, FIDO2, Authenticator app
• Phishing-Resistant: FIDO2 keys, Windows Hello for Business

4.2 Real-World Scenarios

Scenario 1: Financial Trading Platform

Attribute Assignment: SecurityLevel = "Maximum", DataClassification = "Financial", ComplianceFramework = "SEC"

Resulting Controls: Phishing-resistant MFA, compliant corporate device, trusted network only, 1-hour token lifetime, no downloads/printing/copy-paste.

Scenario 2: Healthcare EHR System

Attribute Assignment: DataClassification = "PHI", ComplianceFramework = "HIPAA", SecurityLevel = "Enhanced"

Resulting Controls: Passwordless authentication, compliant device, 4-hour token lifetime, session monitoring, access logging for audit.

Scenario 3: Executive Email and Calendar

Attribute Assignment: UserClassification = "Executive", SecurityLevel = "Enhanced"

Resulting Controls: Passwordless authentication, compliant device or trusted location, 4-hour token lifetime, mobile access requires managed device.

Scenario 4: Developer Tools (GitHub, Azure DevOps)

Attribute Assignment: ApplicationType = "Development", SecurityLevel = "Standard"

Resulting Controls: MFA required, compliant device preferred (not required), 12-hour token lifetime, access from any location.

4.3 Compliance and Regulatory Use Cases

Regulation	Requirements	Attribute Design	CAP Controls
PCI-DSS	Protect cardholder data, restrict access	PCIScope = "InScope"	Phishing-resistant MFA, trusted network, audit logging
HIPAA	Protect PHI, ensure authorized access	DataClassification = "PHI"	Strong authentication, compliant device, session monitoring
SOC 2	Access controls, monitoring, logging	SOC2Critical = "true"	MFA, device compliance, comprehensive logging
GDPR	Protect personal data, access controls	DataClassification = "PII"	MFA, geographic restrictions, audit trail

5. Where Dynamic CAPs Are Used

5.1 Microsoft Entra ID Environment

• Tenant Scope: All attributes and policies exist at tenant level
• Licensing: Included with Entra ID P1/P2 licenses (no additional cost)
• Multi-Tenant: Each tenant manages attributes independently

5.2 Supported Objects

Service Principals (Applications): Enterprise applications, multi-tenant applications, Azure AD Application Proxy applications, and custom line-of-business applications registered in your tenant.

5.3 Cloud and Hybrid Environments

• Pure Cloud: Full support for all cloud-based applications accessed via Entra ID
• Hybrid Identity: Applications published via Azure AD Application Proxy are supported; on-premises applications integrated with Entra ID are supported

6. Who Uses and Maintains Dynamic CAPs

6.1 Role-Based Access Control

Role	Permissions	Responsibilities
Attribute Definition Administrator	Create/manage attribute sets and definitions	Design attribute taxonomy, create attributes, manage lifecycle
Attribute Assignment Administrator	Assign attributes to objects	Tag applications, manage assignments, update values
Conditional Access Administrator	Create/manage CA policies	Create policies with application filters, manage policy lifecycle
Security Administrator	Read security configuration	Monitor policies, review compliance, investigate incidents
Application Owner	Request attribute assignments	Identify security requirements, submit requests, validate controls

6.2 Responsibilities Matrix (RACI)

Activity	Security Team	App Owner	IT Ops	Compliance
Define attribute taxonomy	R, A	C	I	C
Create attribute sets/definitions	R, A	I	I	I
Assign attributes to applications	A	R	I	I
Create Conditional Access policies	R, A	C	I	C
Monitor policy effectiveness	R, A	C	I	I
Audit and compliance reporting	R	I	I	A, R

R = Responsible, A = Accountable, C = Consulted, I = Informed

7. Design Best Practices

7.1 Architecture Principles

1. Baseline First, Enhancements Second: Always implement persona-based baseline CAPs for ALL RESOURCES before adding dynamic policies.
2. Attribute Taxonomy Before Implementation: Design your complete attribute taxonomy before creating attributes. Changes later are difficult and require policy updates.
3. Start Simple, Iterate: Begin with 3-5 core attributes and expand based on real requirements.
4. Document Everything: Maintain comprehensive documentation of attributes, their meanings, and appropriate use cases.
5. Principle of Least Privilege: Apply only the security controls necessary for each application's risk profile.
6. Consistent Naming Conventions: Use clear, standardized naming. Example: CompanyName_Category_AttributeName
7. Test Before Production: Always use report-only mode first. Analyze impact before enforcing policies.
8. Monitor and Measure: Establish KPIs to track policy effectiveness, user impact, and security posture.

7.2 Required Baseline Policies

Policy Name	Users	Applications	Controls
BASE-01: All Users MFA	All Users	All cloud apps	Require MFA
BASE-02: All Users Device	All Users	All cloud apps	Compliant OR Hybrid Joined device
BASE-03: Guests Enhanced	All Guests	All cloud apps	MFA AND Compliant device
BASE-04: Admins Maximum	Directory role members	All cloud apps	Phishing-resistant MFA AND Compliant device AND Trusted locations
BASE-05: Block Legacy Auth	All Users	All cloud apps	Block access (legacy authentication clients)

7.3 Example Attribute Taxonomy

Attribute Set: CompanyName_SecurityLevels — SecurityLevel: Standard, Enhanced, Maximum

Attribute Set: CompanyName_Compliance — DataClassification: Public, Internal, Confidential, PHI, PCI | ComplianceFramework (multi): HIPAA, PCI-DSS, SOC2, GDPR

Attribute Set: CompanyName_AccessControls — NetworkRequirement: Any, Corporate, TrustedOnly | TokenLifetime: 1h, 4h, 8h, 12h

Naming Conventions

Element	Format	Example
Attribute Set	CompanyName_Category	Contoso_Security, Contoso_Compliance
Attribute Name	PascalCase, no spaces	SecurityLevel, DataClassification
Policy Name	PREFIX-##: Description	DYN-CAP-01: Enhanced Security Level

8. Deployment Best Practices

8.1 Pre-Deployment Checklist

Requirement	Status Check	Owner
Entra ID P1/P2 licenses assigned	Verify in license management	IT Operations
Baseline CAPs implemented and tested	Review existing policies covering ALL RESOURCES	Security Team
Break-glass accounts configured and documented	Test emergency access	Security Team
Administrator roles assigned	Confirm Attribute Administrator roles	Identity Team
Attribute taxonomy designed and approved	Documented and reviewed by stakeholders	Security Architecture
Monitoring and logging infrastructure ready	Log Analytics workspace configured	IT Operations

8.2 Step-by-Step Deployment

Phase 1: Setup (Week 1) — Create Attribute Sets and Definitions

Connect-MgGraph -Scopes "CustomSecAttributeDefinition.ReadWrite.All"

$attributeSets = @(
    @{ Id = "ContosoSecurity"; Description = "Security level attributes" }
    @{ Id = "ContosoCompliance"; Description = "Compliance and regulatory attributes" }
)
foreach ($set in $attributeSets) {
    New-MgDirectoryAttributeSet -Id $set.Id -Description $set.Description -MaxAttributesPerSet 25
}

# Create SecurityLevel attribute
$params = @{
    AttributeSet = "ContosoSecurity"
    Name = "SecurityLevel"
    Type = "String"
    Status = "Available"
    UsePreDefinedValuesOnly = $true
    AllowedValues = @(
        @{ Id = "Standard"; IsActive = $true }
        @{ Id = "Enhanced"; IsActive = $true }
        @{ Id = "Maximum"; IsActive = $true }
    )
}
New-MgDirectoryCustomSecurityAttributeDefinition -BodyParameter $params

Phase 2: Policy Creation in Report-Only Mode (Week 2)

# Create dynamic CAP — always start in report-only!
$policyParams = @{
    DisplayName = "DYN-CAP-01: Enhanced Security Level"
    State = "enabledForReportingButNotEnforced"
    Conditions = @{
        Applications = @{
            ApplicationFilter = @{
                Mode = "include"
                Rule = "application.extension_ContosoSecurity_SecurityLevel -eq 'Enhanced'"
            }
        }
        Users = @{
            IncludeUsers = @("All")
            ExcludeUsers = @("break-glass-account-id")  # Always exclude break-glass!
        }
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $policyParams

Phase 3: Assign Attributes to Pilot Applications (Weeks 3-4)

$appId = "your-application-app-id"
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"

$attributes = @{
    "ContosoSecurity" = @{
        "@odata.type" = "#Microsoft.DirectoryServices.CustomSecurityAttributeValue"
        "SecurityLevel" = "Enhanced"
    }
}
Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -CustomSecurityAttributes $attributes

8.3 Break-Glass Account Protection

• At least 2 dedicated accounts (e.g., BreakGlass01, BreakGlass02)
• Cloud-only accounts (not synchronized)
• Strong, unique passwords stored in secure physical location
• Excluded from ALL Conditional Access policies
• Monitored with alerts for any usage
• Tested quarterly to ensure access works

8.4 Testing Checklist

Test Scenario	Expected Result	Status
User accesses app with SecurityLevel=Enhanced	Passwordless MFA required	☐
User accesses app without attributes	Only baseline policies apply	☐
Admin accesses any app	Admin baseline + dynamic policies apply	☐
Break-glass account	Excluded from all dynamic policies	☐
Mobile device access	Appropriate controls based on attributes	☐

9. Monitoring and Logging

9.1 Essential KQL Queries

Query 1: Failed Sign-Ins Due to Conditional Access

SigninLogs
| where TimeGenerated > ago(24h)
| where ConditionalAccessStatus == "failure"
| summarize Count=count() by AppDisplayName, ConditionalAccessPolicies
| order by Count desc

Query 2: Applications Matched by Dynamic CAPs

SigninLogs
| where TimeGenerated > ago(7d)
| extend DynamicPolicy = parse_json(ConditionalAccessPolicies)
| where DynamicPolicy contains "DYN-CAP"
| summarize UniqueApps=dcount(AppDisplayName) by tostring(DynamicPolicy)

Query 3: Attribute Assignment Changes

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName contains "Update service principal"
| where TargetResources contains "customSecurityAttributes"
| project TimeGenerated, Identity, AppDisplayName=TargetResources[0].displayName, Result

9.2 Key Performance Indicators

KPI	Target	How to Measure
Attribute Coverage	>80% of apps have attributes assigned	Count apps with attributes / total apps
Policy Count Reduction	70-80% fewer policies	Compare policy count before/after
Failed Sign-Ins Rate	<2% of total sign-ins	Monitor blocked sign-ins in logs
Time to Onboard New App	<30 minutes	Track from request to attribute assignment

9.3 Critical Alerts

Alert Name	Condition	Action
Break-glass account used	Any sign-in from break-glass accounts	Immediate notification to security team
High CA failure rate	>100 failures in 15 minutes	Page on-call engineer
Unauthorized attribute change	Attribute modified by non-approved user	Alert security team, audit immediately
Policy modification	Any CAP policy created/modified/deleted	Notification to security team

10. Technical Reference

10.1 Attribute Limits and Constraints

Resource	Limit	Notes
Attribute definitions per tenant	500 (active)	Deactivated attributes don't count toward limit
Attribute sets per tenant	500	Hard limit
Attribute name length	32 characters	Unicode, case-sensitive
Attribute value length	64 characters	Unicode
Predefined values per attribute	100	More values = more complex management
Attribute values per object	50	Total across all attributes on single object

10.2 Microsoft Graph API Quick Reference

Operation	HTTP Method	Endpoint
List attribute sets	GET	/directory/attributeSets
Create attribute set	POST	/directory/attributeSets
List attribute definitions	GET	/directory/customSecurityAttributeDefinitions
Create attribute definition	POST	/directory/customSecurityAttributeDefinitions
Assign attribute to app	PATCH	/servicePrincipals/{id}
Get app with attributes	GET	/servicePrincipals/{id}?$select=customSecurityAttributes
Query apps by attribute	GET	/servicePrincipals?$filter=customSecurityAttributes/Set/Attribute eq 'Value'

10.3 Troubleshooting Guide

Issue	Possible Cause	Resolution
Attribute not visible in policy filter	Attribute status is inactive	Activate attribute definition
Policy not matching expected apps	Filter syntax error	Verify attribute set ID and syntax in filter
User blocked unexpectedly	Multiple policies combining controls	Review all policies affecting user/app combination
Cannot assign attribute	Missing Attribute Assignment Admin role	Verify role assignment at tenant or attribute set scope
Break-glass account blocked	Not excluded from policies	Add to exclusions in ALL policies immediately

10.4 PowerShell Script: Bulk Attribute Assignment from CSV

# CSV format: AppId,SecurityLevel,DataClassification
Connect-MgGraph -Scopes "Application.ReadWrite.All", "CustomSecAttributeAssignment.ReadWrite.All"

$apps = Import-Csv "applications.csv"
foreach ($app in $apps) {
    $sp = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'"
    if ($sp) {
        $attributes = @{
            "ContosoSecurity" = @{ "SecurityLevel" = $app.SecurityLevel }
            "ContosoCompliance" = @{ "DataClassification" = $app.DataClassification }
        }
        Update-MgServicePrincipal -ServicePrincipalId $sp.Id -CustomSecurityAttributes $attributes
        Write-Host "Updated: $($sp.DisplayName)"
    } else {
        Write-Warning "App not found: $($app.AppId)"
    }
}

11. Governance and Compliance

11.1 Compliance Framework Mapping

Framework	Relevant Controls	How Dynamic CAPs Help
NIST CSF	PR.AC-1: Identity management; PR.AC-4: Access permissions managed	Granular access controls based on app risk; clear attribute-based authorization
ISO 27001	A.9.2.1: User registration; A.9.4.1: Information access restriction	Consistent access control framework; risk-based access restrictions
SOC 2	CC6.1: Logical access controls; CC6.6: Managed system activities	Documented attribute taxonomy; comprehensive audit logs
PCI-DSS	Req 7: Restrict access by business need; Req 8: Strong authentication	PCIScope attribute for cardholder data apps; enhanced authentication for in-scope apps
HIPAA	§164.312(a)(1): Access control; §164.312(d): Authentication	PHI classification attribute; enhanced controls for PHI applications

11.2 Access Reviews Schedule

Review Type	Scope	Owner	Frequency
Administrator Role Review	All Attribute Administrator role assignments	Identity Team	Quarterly
High-Risk App Attributes	Apps with SecurityLevel=Maximum	Security Team	Quarterly
Policy Effectiveness Review	All dynamic CAPs	Security Architecture	Quarterly
Attribute Taxonomy Review	Is taxonomy still meeting needs?	Governance Committee	Quarterly

12. Conclusion and Recommendations

12.1 Implementation Roadmap

Phase	Timeline	Key Activities	Success Criteria
Phase 0: Foundation	Months 0-3	Implement baseline persona CAPs; configure break-glass accounts; design attribute taxonomy	Baseline policies protecting all resources; documented taxonomy approved
Phase 1: Pilot	Months 3-6	Create attribute sets; create 3-5 dynamic CAPs in report-only; assign attributes to 10-20 pilot apps	Pilot apps successfully tagged; policies working as expected; no unexpected user impact
Phase 2: Production	Months 6-12	Enable policies; expand to 100-200 applications; train application owners	50% of apps with attributes; <2% failed sign-in rate
Phase 3: Maturity	Months 12+	Complete portfolio coverage; optimize; implement automation	>80% app coverage; 70-80% policy reduction achieved; new app onboarding <30 min

12.2 Critical Success Factors

1. Executive Sponsorship: Secure leadership support for the initiative
2. Baseline First: Non-negotiable — implement comprehensive baseline CAPs before dynamic policies
3. Start Simple: Begin with 3-5 core attributes, expand based on real needs
4. Clear Taxonomy: Invest time in designing a clear, logical attribute structure
5. Report-Only Testing: Always test in report-only mode for at least 1-2 weeks
6. Strong Governance: Establish clear ownership, processes, and approval workflows
7. Comprehensive Documentation: Document everything — taxonomy, policies, decisions, procedures
8. Monitor Continuously: Establish KPIs and dashboards, review regularly

Appendix A: Glossary of Key Terms

Term	Definition
Application Filter	A feature in Conditional Access policies that uses expressions to dynamically select applications based on Custom Security Attributes
Attribute Set	A logical container that groups related custom security attributes for organization and delegation
Baseline Policy	A Conditional Access policy that applies to ALL RESOURCES for a specific user persona
Break-Glass Account	Emergency access accounts that bypass all Conditional Access policies
Custom Security Attribute	Business-specific metadata (key-value pairs) that can be assigned to users and applications in Microsoft Entra ID
Dynamic CAP	A Conditional Access policy that uses application filters to dynamically target applications based on their Custom Security Attributes
Phishing-Resistant Authentication	Authentication methods resistant to phishing attacks (FIDO2 security keys, Windows Hello for Business)
Policy Sprawl	The problem of managing too many Conditional Access policies, typically one per application
Report-Only Mode	A CAP state where policies are evaluated but not enforced, allowing impact analysis without affecting users
Service Principal	The instance of an application in your Entra ID tenant; the object to which Custom Security Attributes are assigned

Appendix B: Reference Links

Microsoft Official Documentation

• Custom Security Attributes Overview: learn.microsoft.com
• Conditional Access Overview: learn.microsoft.com
• Application Filters in CA: learn.microsoft.com
• Microsoft Graph API - Custom Security Attributes: learn.microsoft.com

Tools and Utilities

• Microsoft Graph Explorer: developer.microsoft.com
• Microsoft Graph PowerShell SDK: learn.microsoft.com

Appendix C: Pre/Post Deployment Checklists

Pre-Implementation

Task	Complete
Baseline persona-based CAPs implemented for ALL RESOURCES	☐
Break-glass accounts configured and tested	☐
Entra ID P1/P2 licenses verified	☐
Attribute Administrator roles assigned	☐
Attribute taxonomy designed and documented	☐
Stakeholders identified and engaged	☐
Log Analytics workspace configured	☐

Post-Deployment

Task	Complete
Monitoring dashboards created	☐
Alert rules configured	☐
KPIs established and tracking	☐
Application owners trained	☐
Governance committee established	☐
Quarterly review schedule established	☐