Kerberos constrained delegation allows a service to present a user’s Kerberos identity to specific downstream services without unrestricted delegation. Microsoft Entra ID does not provide native Kerberos constrained delegation for cloud-only identities, so it is usually a hybrid design issue. Review which services are allowed to delegate, limit scope tightly, and monitor for abuse of delegated tickets.
How constrained delegation fits into a hybrid Entra ID design
Kerberos constrained delegation is a way to let one service act on a user’s behalf only to explicitly approved downstream services. In a hybrid microsoft entra id environment, the practical question is less “does Entra ID replace Kerberos delegation?” and more “which on-premises or integrated services still depend on Kerberos ticket delegation, and where does the trust boundary stop?”
That matters because delegation is powerful only when the service boundary is well defined. If a front-end service can request tickets for too many back-end targets, it can turn a normal user session into broad lateral access. The safer pattern is to treat delegation as a narrowly scoped exception, not a general identity feature.
When Kerberos delegation is part of a broader hybrid identity design, the control surface usually sits in Active Directory, not in cloud-only Entra ID objects. NHI Management Group’s Kerberos Delegation Security Guide is the best starting point for understanding the protocol mechanics behind constrained delegation, protocol transition, and the abuse conditions that show up in real environments.
Entra ID still matters because hybrid identity often connects cloud access, sync infrastructure, and application credentials to the same enterprise trust fabric. NHIMG’s Active Directory and Entra ID Hardening Guide is useful here because delegation issues rarely stay isolated, they usually sit alongside service accounts, federation, sync paths, and privileged access controls.
What constrained delegation actually allows and what it does not
Constrained delegation lets a service obtain service tickets to specific downstream services after a user authenticates to the first service. The critical property is limitation: the front-end should only be able to delegate to the exact services it needs, not to any service it can discover. That is why the allowed-to-delegate-to list, SPN scoping, and account sensitivity settings matter so much.
Microsoft Entra ID does not provide native Kerberos constrained delegation for cloud-only identities, so the implementation question is usually about hybrid services, domain-joined applications, and supported authentication flows. If your architecture expects a cloud-only identity to behave like an on-prem Kerberos principal, you are already in design-risk territory and should revisit the trust boundary rather than forcing the model.
Constrained delegation is also different from modern token-based delegated access. Kerberos delegation is about Kerberos ticket presentation across services, while cloud delegation patterns in Entra ID often use OAuth consent, app permissions, or token exchange semantics instead. Mixing those models without a clear boundary is a common source of confusion and over-permissioning.
For the Kerberos-side mechanism, NHI Management Group’s Kerberos Security Guide provides the adjacent controls and attack paths that help explain why delegation scope, ticket handling, and monitoring are inseparable from account protection.
For the cloud-side boundary, Entra ID Applications and Consent Guide helps distinguish delegated Kerberos behavior from Entra application consent, Graph permissions, and token-driven access.
How to review and limit delegation safely in practice
Start by identifying every service account, application pool, or middle-tier component that is allowed to delegate. Then verify that each target service is explicitly necessary, that no broad wildcards or legacy allowances remain, and that sensitive accounts are blocked from delegation. If a service does not need to impersonate users to a downstream system, it should not be delegated at all.
Hybrid environments also need operational guardrails around directory sync, federation, and privileged access. A delegation path that looks harmless on paper can become a privilege-escalation path if the front-end account is compromised or if the downstream target is over-trusted. That is why delegation review should be paired with service-account inventory, admin-group review, and incident monitoring.
If the delegated path touches privileged identity, use just-in-time activation and tight approval workflows around the administrative identities that can change or inspect that configuration. NHIMG’s Privileged Identity Management (PIM) Guide is relevant because the operational risk often comes from who can modify delegation, not only from who can use it.
Where the hybrid estate relies on synchronization or federated trust, Storm-0501 hybrid cloud attacks 2024 illustrates why identity trust paths, sync credentials, and token-forging opportunities deserve the same scrutiny as the delegation setting itself.
Risk and Threat Considerations
Constrained delegation is attractive to attackers because it turns one compromised service into a proxy for user access to other systems. In a hybrid design, the risk is highest when the delegated service is broad, the account is privileged, or the environment still contains legacy trust assumptions that were never revisited after Entra ID adoption.
Failure mechanism: A compromised front-end service account can request or replay delegated Kerberos tickets to approved back-end services, and if the approved list is too broad, the attacker gains a legitimate-looking path to sensitive resources.
Impact: The likely consequences are lateral movement, unauthorized access to back-end applications, and in some environments privilege escalation through service abuse or credential exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Kerberos delegation in hybrid trust flows depends on authenticating non-user service access correctly. |
| AC-6 — Least Privilege | Constrained delegation is fundamentally about limiting which downstream services can be reached. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Delegated ticket abuse is best detected through review of authentication and service access logs. | |
| Recommendation — Apply IA-9 to constrain and validate delegated service authentication paths. Enforce AC-6 so delegated identities can reach only required services. Use AU-6 to monitor delegated access patterns for abuse. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Delegation scope can over-privilege service identities if targets are too broad. |
| NHI-07 — Long-Lived Secrets | Hybrid delegation setups often rely on service credentials that become durable attack paths. | |
| Recommendation — Reduce delegated service privileges to the minimum target set. Replace durable service secrets with shorter-lived credentials where possible. | ||
| MITRE ATT&CK | T1134 — Access Token Manipulation | Delegated access can be abused to act through another identity or ticket path. |
| T1550 — Use Alternate Authentication Material | Kerberos tickets and related materials can be reused or stolen to access services. | |
| Recommendation — Map delegated access abuse to T1134 and hunt for impersonation patterns. Detect misuse of alternate authentication material across service paths. | ||
Practitioner Guidance
What to verify: Confirm whether the delegation path is actually required for the business flow, and check whether each allowed target service is still in use and still appropriate. Review the account type, SPN registration, and whether any sensitive users or admin accounts are excluded from delegation.
What to prioritise: Prioritise the front-end identities that can reach the widest set of downstream services, because they carry the largest blast radius if compromised. In hybrid estates, the highest-risk cases are usually service accounts that also have directory, sync, or application administration reach.
Decision rule: If the same service can accomplish the workflow without impersonating the user to another system, remove delegation rather than leaving it in place as a convenience. If delegation is essential, constrain it to the smallest possible service set and monitor the ticketing path for unusual patterns.
Practitioner takeaway: The main control question is not whether delegation exists, but whether every delegated hop is still necessary, narrowly scoped, and observable enough that abuse would be detectable before it becomes lateral movement.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org