Look for application identities with missing owners, stale credentials, unused permissions, and no recertification trail. When service principals are never reviewed, they become hidden persistence points and credential targets, especially in Azure environments where they can be used long after the original project has changed or ended.
What failing service-principal governance looks like in practice
Service-principal governance fails when the identity exists longer than its business purpose, no one can explain who owns it, and its permissions drift away from the original need. The signal is less about a single misconfiguration and more about accumulated neglect: stale credentials, broad access, and missing review evidence that leave the principal able to act without current accountability.
A healthy governance model ties each service principal to a documented owner, a clear purpose, and a review cadence. When those basics disappear, the identity becomes hard to justify, harder to audit, and easier to miss during incident response. In Azure, that is especially dangerous because app registrations and enterprise applications can continue to authenticate long after the project or team that created them has changed.
One practical sign is that the principal still has active secrets or certificates but no one knows whether they are still needed. Another is that the application is granted more roles or scopes than the workload actually uses. If you see privileges that were added “temporarily” and never removed, governance is already lagging behind operational reality.
What the review trail should show if governance is working
Good service-principal governance leaves evidence: an assigned owner, a recorded business purpose, periodic recertification, and documented rotation or removal decisions for credentials. That evidence should make it easy to answer three questions quickly: who is responsible, why the principal exists, and whether its access still matches the current workload.
When the review trail is absent or incomplete, the security team is forced to infer intent from logs and configuration history. That usually means the identity was never built with lifecycle control in mind. It also means the organisation may be depending on an application credential that nobody is actively watching, which is a classic condition for silent persistence.
Watch for principals that have been untouched across multiple ownership changes, tenant restructures, or project shutdowns. If no recertification date exists, or if reviews happen only after an incident, the governance process is functioning as an after-the-fact cleanup activity rather than a control.
Why stale permissions and unattended credentials matter
Stale permissions expand blast radius. A service principal that keeps rights it no longer needs can be abused for data access, configuration changes, or lateral movement into other Azure and Microsoft 365 assets. Unused access is not harmless just because it is quiet, it is valuable precisely because it is easy to overlook.
Unattended credentials are even more sensitive because they are often the easiest path to impersonation. Once a secret or certificate remains valid beyond its intended lifetime, the principal can become a long-lived persistence point that survives normal user offboarding and project turnover. Cloud Workload Identity Guide is useful background for the Azure pattern, especially where service principals are still being used instead of shorter-lived or federated approaches.
In real environments, this is where governance and compromise overlap. A dormant application identity with broad rights is attractive both as an operational shortcut and as an attacker foothold. Malwarebytes breach 2021 and Storm-1283 OAuth apps abuse 2023 both show how application credentials can be turned into durable access and monetised abuse.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Service-principal governance hinges on credential lifecycle, rotation, and revocation. |
| AC-2 — Account Management | Missing owners, stale accounts, and unused identities are account-management failures. | |
| AC-6 — Least Privilege | Overprivileged service principals create unnecessary blast radius and persistence risk. | |
| Recommendation — Enforce secret rotation, expiration, and revocation for application credentials. Inventory, assign owners, and disable or remove unused service principals. Trim service-principal permissions to the minimum required for the workload. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The issue is governed identity ownership, provisioning, review, and removal. |
| Recommendation — Maintain identity ownership, lifecycle records, and periodic review for service principals. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Dormant service principals often persist after the workload or project has ended. |
| NHI-05 — Overprivileged NHI | Unused permissions and broad roles are core signs of governance failure. | |
| NHI-07 — Long-Lived Secrets | Stale credentials turn service principals into durable persistence points. | |
| Recommendation — Retire service principals when their owning workload or project is decommissioned. Review and reduce service-principal privileges to current operational need. Replace long-lived secrets with shorter-lived or federated authentication. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Service-principal governance depends on complete inventory of application identities. |
| PR.AA-05 — Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties | Unused permissions and broad roles are direct authorization-management failures. | |
| Recommendation — Inventory service principals and keep the authoritative register current. Continuously recertify and reduce service-principal permissions. | ||
Practitioner Guidance
What to verify: Confirm every service principal has a named owner, a stated business purpose, a current credential expiry or rotation plan, and a recent access review. If any one of those is missing, treat the identity as a governance exception, not a low-priority housekeeping item.
Decision rule: If the principal can still authenticate but nobody can justify its access, prioritise ownership assignment and credential rotation before debating whether the permissions are “probably fine.” If the workload is finished, retire the identity rather than preserving it for convenience.
What good looks like: The organisation can inventory all service principals, explain why each exists, show who approves access, and prove that unused permissions are removed on a schedule. That state is observable in records, not just in control claims.
Practitioner takeaway: The failure mode is not merely excess access, it is the loss of accountable lifecycle control, because an unowned service principal with valid credentials can outlive the business need that created it.