Conditional Access Essentials: Custom Security Attributes in Entra ID and Cross Tenant Scenarios

Introduction

We’ve already covered personas, named locations, authentication strengths, and service principals in this Conditional Access Essentials series. But there’s still a tricky gap worth exploring: what do you do when you need to target an app in Conditional Access, but it doesn’t appear in the policy picker?

Enter custom security attributes. Think of them as sticky notes you can attach to an app or service principal so Conditional Access can recognise it later. They’re ideal for edge cases, legacy apps, or those sneaky Microsoft services that don’t appear in the default policy list.

In this post, we’ll look at custom security attributes and cross-tenant access settings - two powerful tools that help you fine-tune policies and keep your Zero Trust model strong, even when users hop between tenants or use apps that aren’t visible in the standard picker.

Table of Contents

Why are custom security attributes necessary?

Understanding attribute sets, attribute names, and attribute values

Setting up custom security attributes in Entra ID

Assigning attributes to apps: examples & use cases

Using attributes in conditional access policies

Scenario walkthroughs

Cross-Tenant Access Settings Explained

Conclusion

Why are custom security attributes necessary?

Conditional Access lets you scope policies to “cloud apps”. That works fine for the big names like Teams, Exchange, SharePoint, and Office 365. But not everything shows up in the picker.

Microsoft bundles many back-end services under single entries like Office 365. It’s convenient but limits how granular you can be. Examples of apps that historically couldn’t be targeted directly include:

• Azure AD PowerShell

• Graph Explorer

• Microsoft Azure CLI

• Microsoft Exchange REST API-based PowerShell

• Microsoft Invitation Acceptance Portal, and many more...

  
  

Custom security attributes fill this gap. They’re metadata you assign to enterprise applications (service principals) that Conditional Access can filter on. This gives you the flexibility to:

• include or exclude apps that aren’t visible in the UI

• apply policies based on personas or other attributes

• protect legacy apps or unique integrations

For example, you can tag the Azure CLI or Exchange REST API with a policyRequirement value like requireMFA and enforce MFA through Conditional Access, even if the app isn’t listed.

Understanding attribute sets, attribute names, and attribute values

Custom security attributes have a hierarchy:

Attribute set

• Definition: a container for related attributes.

• Purpose: organises attributes logically.

• Example: conditionalAccess

• Analogy: a folder holding all your Conditional Access persona attributes.

  
  

Attribute name

• Definition: a property within the attribute set.

• Purpose: identifies the type of access or restriction.

• Examples:

  • personaGrant -> Users explicitly allowed access

  • personaBlock -> Users explicitly denied access

• Analogy: Labels on files in your folder, indicating the rule type.

  
  

Attribute values

• Definition: The actual value assigned to an attribute for a specific app or user.

• Purpose: Specifies who or what is affected.

• Examples:

  • admins -> Assigned to personaGrant

  • guests -> Assigned to personaGrant

• Analogy: Sticky notes on your labelled files, showing exactly which users or groups the rule applies to.
  

The table below depicts some examples of what custom attribute set can consist of:

Attribute Set	Attribute Name	Attribute Value	Apps Assigned
conditionalAccess	personaGrant	admins	e.g. Azure AD PowerShell, Graph Explorer
conditionalAccess	personaGrant	guests	e.g. Microsoft App Access Panel, Microsoft Invitation Acceptance Portal
ConditionalAccessTaggedApps	policyRequirement	legacyAuthAllowed	e.g. some legacy app
ConditionalAccessTaggedApps	policyRequirement	requireCompliantDevice	Exchequer/ SAP/ any 3rd party app that you are unable to select

Therefore in some cases, as an example:

• the attribute set groups all persona attributes.

• the attribute names define whether the persona is allowed or denied access.

• the values specify exactly which users fall into each persona.

  
  

Setting up custom security attributes in Entra ID

Step 1: Create an attribute set

• Sign in to Microsoft Entra Admin Center

• Navigate to Entra ID > Custom Security Attributes

• Click Add Attribute Set, e.g., ConditionalAccessTaggedApps or conditionalAccess and when ready select Add.

  

Step 2: Define attributes

• Click into your attribute set and select Add attribute. Name: examples: policyRequirement/ personaBlock/ personaGrant/ AllowPersona/ BlockPersona

• Type: String (Conditional Access only supports strings)

• Allow multiple predefined values, e.g.:

  • admins

  • internals

  • guests

  • externals

  • legacyAuthAllowed

  • blockGuests

  • blockExternals

  • requireMFA

  • requireCompliantDevice

Step 3: Assign roles & permissions Custom attributes are security-sensitive. Only users with delegated roles can manage them:

• Attribute Assignment Administrator - assign keys/values to apps

• Attribute Assignment Reader - view assigned keys/values

• Attribute Definition Administrator - create/edit attribute definitions

• Attribute Definition Reader - view attribute definitions

Tip: Global Admins do not automatically have these permissions.

Assigning attributes to apps: examples & use cases

Scenario: Requiring a compliant device for a specific application that you aren't able to explicitly select within the target resources of your conditional access policy

Steps:

1. Go to Enterprise Apps > Select App > Custom Security Attributes > Add Assignment
   

   

2. Attribute Set: ConditionalAccessTaggedApps

3. Attribute Name: policyRequirement

4. Assign Value: RequireCompliantDevice

5. Save

Use case:

• App: 'Example App'

• Result: Users will need to come from a compliant device when signing into your app.

Using attributes in conditional access policies

Once your app is tagged, building a policy is simple:

1. Create a new Conditional Access policy

2. Assign users or groups

3. Target Cloud Apps > Edit filter > Configure = Yes

4. Filter by attribute: for example 'policyRequirement' Contains 'requireCompliantDevice'

5. Access Controls: Grant > Require device to be marked as compliant
   

   

6. Enable in Report-only mode first to test

Scenario example:

• A new user signs into SAP.

• Conditional Access sees the custom attribute > compliant device is required.

• Other apps without the attribute remain unaffected.

  
  

Custom attributes also work well for:

• Blocking legacy authentication for specific apps

• Blocking external users

• Applying session controls for high-risk users

• Requiring privileged access workstations

• Excluding a specific app from the MFA requirement (ideally your policies should always target all users and all resources when requiring MFA but we don't live in an ideal world).

I realise that every organisation has different requirements and varying levels of appetite for granularity. So, set up as many or as few attribute sets and attributes as you like, whatever works best for your environment.

Scenario walkthroughs

I’m going to walk you through two scenarios to illustrate how this can work in practice.

Scenario 1

In this scenario, we don’t want to be overly granular, and we’re not correlating our attribute sets or attributes with any personas. Instead, we simply want to tag the applications that can’t be natively selected within the scope of target resources in Conditional Access and divide them into a few groups. These groups are:

• Applications that still require legacy authentication

• Applications that require access from compliant devices

• Applications that do not require MFA

• Applications that should be accessed by everyone within my organisation, but not by guests or externals

  
  

In this situation, we’ll start by creating our custom security attributes in Entra.

1. Navigate to Entra ID in the Entra Admin Centre and go to Custom Security Attributes.

2. Click Add Attribute Set and name the attribute set ConditionalAccessTaggedApps.
   

   

Next, we need to define our attributes.

1. Click into your newly created custom security attribute set, in my case, ConditionalAccessTaggedApps, and select Add attribute
   

   

2. Give your attribute a name. I’m calling mine policyRequirement. Fill out the description if needed.

3. Set Data type to String (as this is what Conditional Access supports).

4. Set Allow multiple predefined values to Yes.

5. Set Only allow predefined values to be assigned to Yes.
   

   

6. Beside Predefined values, click Add value.
   

   

I’m going to match the requirements of my apps to the attribute values as follows:

• Applications that still require legacy authentication -> legacyAuthAllowed

• Applications that require access from compliant devices -> requireCompliantDevice

• Applications that do not require MFA -> DoNotRequireMFA
  

  

• Applications that should be accessed by everyone within my organisation but not by guests or externals -> blockGuests and blockExternals
  

  

Next, we need to assign attributes to our app. I’ll use an app called Example App in my environment, but this could be any application that you can’t explicitly target in your policies. The application must already exist in your tenant. If it doesn’t, you’ll need to set it up first.

1. Navigate to Entra ID > Enterprise Apps > 'Example App' > Custom Security Attributes > Add Assignment.
   

   

   

   
   

   

2. Attribute Set: ConditionalAccessTaggedApps

3. Attribute Name: policyRequirement
   

   

   

   

4. Assigned Values: legacyAuthAllowed and requireCompliantDevice (but you can assign as many as you need). > Done.
   

   

5. Click Save.

   
   

Once this is done, you’re ready to create your Conditional Access policy. Previously, I wasn’t able to select my app within the target resources of my policy, but now that I’ve assigned a custom security attribute, it becomes possible.

1. In Entra ID > Conditional Access, create a new Conditional Access policy.

2. Assign users or groups (include all, exclude emergency/break-glass accounts).

3. Target Cloud Apps > Include > Edit filter > Configure = Yes.

4. Filter by attribute: for example, policyRequirement contains requireCompliantDevice.

5. Access Controls: Grant -> Require compliant device.

6. Enable in Report-only mode first to test.
   

   

   
   

To block legacy authentication for all apps except Example App, which still requires it, you can flip the scenario and configure your Conditional Access policy as follows:

1. In Entra ID > Conditional Access, create a new Conditional Access policy.

2. Assign users or groups (include all, exclude emergency/break-glass accounts).

3. Target Cloud Apps > Include: All resources & Exclude > Edit filter > Configure = Yes.

4. Filter by attribute: for example, policyRequirement contains legacyAuthAllowed.

5. Specify your conditions: Conditions > Client Apps > Legacy authentication clients: Exchange ActiveSync clients & Other clients.

6. Access Controls: Grant > Block.

7. Enable in Report-only mode first to test.
   

   

Scenario 2

In this scenario, we want to be a bit more granular. Imagine a specific set of applications that only admin users should be able to use - for example, Microsoft Graph, Graph Explorer, Azure AD PowerShell, etc. These haven’t always been selectable in Conditional Access policies.

Let’s say we have an application called PowerShell, which in this case represents different versions of PowerShell, Graph, CLI, and so on that you may wish to allow/ block for various users. We only want to allow the Admin persona to use it while blocking other personas.

First, we’ll create our custom security attributes in Entra.

1. Navigate to Entra ID in the Entra Admin Centre and go to Custom Security Attributes.

2. Click Add Attribute Set and name the attribute set conditionalAccess.

Next, we need to define our attributes.

1. Click into your newly created custom security attribute set - in my case, conditionalAccess.

2. Give your attribute a name. I’m calling mine personaBlock. Fill out the description if needed.

3. Set Data type to String (as this is what conditional access supports).

4. Set Allow multiple predefined values to Yes.

5. Set Only allow predefined values to be assigned to Yes.

6. Beside Predefined values, click Add value.

I’m going to match the requirements of my apps to the values as follows: personaBlock = externals, internals, guests

Next, we need to assign attributes to our app. I’ll use an app called PowerShell, but this could be any application you can’t explicitly tag in your policies. As before, the app must exist in your tenant first.

1. Navigate to Entra ID > Enterprise Apps > PowerShell > Custom Security Attributes > Add Assignment.

2. Attribute Set: conditionalAccess

3. Attribute Name: personaBlock

4. Assigned Values: externals, internals, guests.

5. Click Save.
   

   

You can also create a personaGrant or personaAllow attribute if needed.

Other similar apps you can control this way include Graph Explorer, Microsoft CLI, Exchange REST API, and Microsoft Invitation Acceptance Portal.

Once that’s done, you’re ready to create your Conditional Access policy. Previously, it wasn’t possible to select this app in the policy’s target resources, but assigning a custom security attribute now makes it possible.

1. In Entra ID > Conditional Access, create a new Conditional Access policy.

2. Assign users or groups (include all, exclude the CA-Admins persona + emergency/break-glass accounts).

3. Target Cloud Apps > Include > Edit filter > Configure = Yes.

4. Filter by attribute: for example,

   • personaBlock contains internals OR

   • personaBlock contains externals OR

   • personaBlock contains guests.

5. Access Controls: Grant > Block.

6. Enable in Report-only mode first to test.

While custom security attributes are powerful, they do come with a few limitations. Not every app respects or triggers Conditional Access evaluations in the same way - particularly some legacy service principals or deeply integrated Microsoft first-party apps. For example, if an app uses authentication flows that bypass modern auth or Conditional Access evaluation points (such as certain daemon apps or legacy protocols), your attribute-based policies may not apply as expected. Additionally, the attribute filtering feature is only supported for enterprise apps (service principals); not for every resource type. Attributes also don’t retroactively surface apps in the UI; they simply provide a filter for policies. Finally, role requirements can catch people off guard - Global Admin alone isn’t enough to manage assignments, so correct delegated roles must be in place.

Cross-tenant access settings explained

Custom security attributes are brilliant for targeting resources within a single tenant, but what happens when you need to manage multi-tenant or B2B collaboration scenarios? That’s where cross-tenant access settings in Entra ID come into play.

Entra ID allows you to trust authentication claims - such as MFA and device compliance - from a user’s home tenant. This brings two major benefits:

• Productivity: users don’t need to re-register MFA when accessing your organisation’s resources.

• Security: supports strong, phish-resistant MFA methods (e.g. FIDO2 security keys), maintaining Zero Trust principles even across tenants.
  

Inbound vs outbound control

Cross-tenant access settings give you flexibility through default and per-tenant controls, letting you decide who can collaborate with your organisation, and where your users can go:

• Inbound access - controls which external tenants’ users can access your resources.

• Outbound access - controls which external tenants your users can sign into.
  

Real-world example

Let’s say your partner organisation needs access to a shared line-of-business app hosted in your tenant. By configuring cross-tenant trust, you can accept MFA claims from their home tenant while still applying your Conditional Access policies.

The result? A frictionless sign-in experience for partner users - without compromising security.

How to configure cross-tenant access

1. Navigate to Entra ID > External Identities > Cross-Tenant Access Settings.

2. Configure your default policies to allow or block inbound and outbound collaboration.

3. Add per-tenant overrides to fine-tune access for trusted partners.

Enabling MFA & device claim trust

Entra ID can trust MFA and device compliance claims from other Entra ID tenants. This is particularly useful for B2B collaboration and B2B direct connect scenarios.

If your Conditional Access policies require MFA and you want to enable B2B direct connect with another organisation, you must configure inbound trust. This ensures that Conditional Access will accept MFA claims from the external tenant, streamlining access while maintaining security.

Scenario: Trust MFA & device compliance from partnerdomain.onmicrosoft.com Let me walk you through a real life scenario now.

Goal: Accept MFA and compliant-device claims from a partner tenant so their users can sign in to our shared app without re-registering MFA - while keeping control and auditability.

Quick checklist (what we’ll do)

1. Verify partner identity and get tenant identifier (FQDN or tenant ID).

2. Confirm permissions and ownership details.

3. Add partner organisation in Entra.

4. Customise inbound trust to accept MFA and device claims.

5. Test sign-in with a partner user.

6. Check sign-in logs and conditional access evaluation.

7. Monitor, audit and roll back if needed.

Pre-reqs & safety checks (do these first)

• You need the right role in your tenant (Global Administrator or appropriate External Identities / Cross-tenant admin role).

• Get the partner to confirm their tenant ID or the primary domain, e.g. partnerdomain.onmicrosoft.com. Verify this directly with a named contact. Don’t rely on a casual email.

• Agree with the partner on the minimal security posture you will accept (MFA type, device management, Conditional Access expectations). If you can, insist on phish-resistant MFA (FIDO2/WHfB) for high-risk access.

• Decide scope: will trust apply to all inbound users from the partner, or only specific apps/conditions? Prefer scoped trust (per-tenant overrides) rather than blanket trust.

Step-by-step: Configure inbound trust for the partner

1. Add the partner organisation

1. Sign in to the Entra admin centre.

2. Go to External Identities > Cross-tenant access settings.

3. Under Organisational settings, click + Add organisation.
   

   

4. Enter the partner’s tenant FQDN or tenant ID (e.g. partnerdomain.onmicrosoft.com) and click Add.
   

   

   Tip: record who supplied the tenant ID and when. Store that in your partner onboarding notes.

2. Open the inbound trust settings for the tenant

1. Next to the newly added org, click Inherited from default under Inbound access.
   

   

2. Click Trust settings.

3. Choose Customise settings (don’t stick with inherited defaults unless you’ve checked them).

3. Enable MFA and device claim trust

In the inbound Trust settings, change from Default settings to Customize settings and check the appropriate options

• Trust multi-factor authentication from Entra ID tenants - Enable.

  • This allows Conditional Access in your tenant to accept the partner’s MFA claim instead of forcing re-registration.

• Trust compliant devices - Enable if you trust the partner’s device compliance posture.

  • This lets you accept device-compliance claims (MDM/compliance) from the partner tenant.

• Trust hybrid Entra joined devices - Enable if the partner uses hybrid-joined devices you want to trust.
  

  

Save the settings.

Security note: If you’re unsure about the partner’s device posture, enable Trust multi-factor authentication first and delay trusting device claims until you verify their Intune / device compliance controls.

4. Scope or limit the trust (recommended)

• Use per-tenant overrides to limit trust to specific apps or scenarios where it’s necessary.

• If possible, restrict inbound trust to just the app(s) you are sharing. This reduces blast radius.

  
  

Step-by-step: Test & verify

5. Test sign-in with a partner user

1. Ask the partner to sign in to the shared app (or to a test app) using their home-tenant account.

2. Watch the experience: the user should not be asked to re-register MFA in your tenant. If you allowed device claims, device compliance flows should be accepted from their home tenant.

6. Check sign-in and Conditional Access logs

1. In the Entra admin centre, go to Monitoring > Sign-ins.

2. Filter by the partner user or the app.

3. Open the sign-in record and review the Conditional Access tab. Look for:

   • Evidence that the MFA requirement was satisfied by an external claim.

   • Any device claims that arrived from the partner (compliance/hybrid join).

4. If you need deeper detail, export logs or use the Graph sign-in API for forensic data.

7. Audit and monitoring

• Add alerts for unusual inbound sign-ins or for failures where MFA claims arrive but are insufficient.

• Review the sign-ins and Conditional Access events for the first few weeks.

• Ask the partner to provide attestation of their MFA and device compliance posture (periodically).

Rollback & troubleshooting

• If the partner user is blocked or you see suspicious behaviour, immediately revoke the tenant override or change inbound trust to Block.

• If MFA claims are not accepted, verify the partner’s configuration and that their MFA is producing the expected claims.

• If device claims fail, either disable device trust for that partner or work with their device team to ensure compliance signals are sent.

Pitfalls, risks & mitigations

• Trusting a weak partner posture: don’t trust MFA blindly. Require evidence or insist on phish-resistant methods for critical access.

• Too broad a trust scope: avoid trusting all apps from the partner by default. Limit to specific apps where possible.

• Audit gaps: set up monitoring and alerts; don’t assume trust removes the need to log and review.

• Token/claim mismatch: if claims don’t map to what your CA expects, authentication will fail. Test thoroughly.

• Human error: document the process, who added the tenant, and why. Keep change control.

If you trust MFA and compliant-device claims from partnerdomain.onmicrosoft.com, your partner’s users get a far smoother experience. They sign in once, keep their MFA setup in their home tenant, and your Conditional Access still enforces the policy outcome you expect; provided you scope and test the trust carefully. Start small: enable MFA trust only, test with a handful of users, review sign-in logs, then consider adding device-claim trust. Keep everything scoped and auditable, and insist on at least equivalent assurance from the partner, anything less and you’re buying convenience at the cost of potentially weaker security.

Conclusion

Custom security attributes and cross-tenant access settings fill an important gap in Conditional Access strategy. They give you the flexibility to secure apps that don’t appear in the policy picker, apply granular controls based on personas or requirements, and extend trust intelligently across tenant boundaries. Whether you’re locking down legacy tools, enforcing MFA on hidden services, or streamlining B2B collaboration, these features give you precision without compromising security. With thoughtful design and testing, they can elevate your Conditional Access policies from broad strokes to finely tuned controls, keeping your Zero Trust model both solid and adaptable.