Topic starter
08/07/2026 6:54 pm
TL;DR: Service principals in Microsoft 365, Intune, Defender, and Entra ID can hold standing secrets, broad permissions, and directory roles without MFA or user-facing controls, creating a persistent attack path according to Senserva. That makes workload identity inventory, consent review, and credential expiry core IAM work, not optional hygiene.
Editorial analysis by NHI Mgmt Group, based on content published by Senserva: “How to Find Risky Service Principals in Entra ID”.
Key questions
Q: What breaks when service principals have standing secrets and broad permissions?
A: They become durable, low-friction access paths that do not depend on a human user, so MFA, Conditional Access, and normal user review no longer constrain the identity.
Q: Why do service principals with privileged Graph access create higher tenant risk?
A: Because application permissions can act without a signed-in user, so a high-privilege app can read, write, or administer data at scale with no interactive checkpoint.
Q: How do organisations know if service principal governance is working?
A: Service principal governance is working when every non-user identity has clear ownership, policy is versioned and tested, and downstream logging can distinguish service activity from end-user activity.
Practitioner guidance
- Inventory every service principal by effective privilege List application permissions, delegated grants, and directory roles together so the highest-risk identities are visible first, not buried by app name.
- Enforce secret and certificate expiry Flag never-expiring secrets, multi-year certificates, and multiple active credentials on the same app, then treat them as immediate review items.
- Review tenant-wide consent and role assignments Check for broad Microsoft Graph scopes, unexpected admin consent, and any service principal assigned privileged directory roles.
Bottom line: Service principals are not secondary tenant objects. They are non-human identities with the ability to hold standing access, broad permissions, and privileged roles.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/07/2026 7:16 pm
Standing application identity is a governance problem, not an application detail. Service principals behave like permanent access objects unless lifecycle controls force them back into review. That shifts them squarely into IAM and IGA scope, because the risk is created by permission persistence, ownership drift, and missing expiry discipline. The practitioner conclusion is simple: if the identity can act after the project ends, governance has failed.
A question worth separating out:
Q: When should organisations prioritise service principal cleanup over other IAM work?
A: When application identities hold directory roles, tenant-wide Graph permissions, or credentials with no expiry, they should move ahead of lower-impact access tasks. Those identities can outlive the project, bypass user-centric controls, and keep a breach path open long after the original owner has moved on.
👉 Read our full editorial: Service principals are the hidden risk in Entra ID tenants