Vendor Access via Service Principals

During a Microsoft Azure tenant review, a security team identified a service principal that had been granted Contributor-level access to the organization's entire subscription , one of the broadest permission levels available short of Owner. The service principal had been created by a software vendor during an implementation project two years earlier. The project had concluded. The vendor's human user accounts had been removed. But the service principal , the non-human identity the vendor's application used to authenticate and operate in the tenant , was still there, fully active, with valid credentials stored in the vendor's systems, carrying permissions that would allow anyone who compromised them to read, modify, and delete resources across the entire Azure environment. Two years. No review. No expiry. No monitoring. Nobody had thought to ask whether the application still needed to exist, let alone what it could do.

What is a Service Principal, Really?

A service principal is a non-human identity created in a cloud identity platform , most commonly Azure Active Directory, but the concept exists across all major cloud providers under different names , that represents an application, service, or automated process rather than a person. Where a human user logs in interactively with a username, password, and potentially MFA, a service principal authenticates programmatically using a client secret, a certificate, or a federated credential. It is the identity through which vendor applications, integrations, and automated pipelines operate in your cloud environment without requiring a human to be present.

The governance implications of service principals differ from human identities in several critical ways. A service principal has no concept of an interactive session , it authenticates continuously, at machine speed, on whatever schedule the application demands. It is not subject to MFA because there is no human to challenge. It does not have a working-hours pattern that would make off-hours activity suspicious in the way it would be for a human account. It does not forget its credentials when an employee leaves the organization. And it typically carries permissions scoped to what the application was designed to do at its broadest , not what it needs to do in normal operations, which is often a much narrower set of actions.

In the vendor context, service principals represent a specific governance challenge that sits between identity management and third-party risk. When a vendor creates a service principal in your Azure tenant , or when you create one on their behalf , you have introduced a persistent, non-human identity with defined permissions and vendor-held credentials into your environment. That identity will continue to exist and authenticate until someone explicitly deactivates it. Its credentials will continue to be valid until someone rotates or revokes them. And its activity will be invisible unless someone has specifically configured monitoring for it. The vendor's human staff may come and go, their user accounts may be provisioned and deprovisioned, but the service principal they created on day one of the engagement has a strong tendency to outlast all of them.

Service principal risk in vendor relationships breaks down across four compounding dimensions:

• Credential persistence , client secrets and certificates associated with vendor service principals typically have multi-year expiry dates or no expiry at all, remaining valid indefinitely unless actively managed
• Permission accumulation , service principals provisioned with broad permissions at integration setup that are never right-sized as the actual usage pattern becomes clear over time
• Lifecycle abandonment , service principals that persist after the vendor engagement, project, or relationship ends because deprovisioning was never triggered
• Monitoring absence , service principal activity not surfaced in standard identity governance reviews because non-human identities are frequently excluded from access review processes designed around human users

Why this matters

Service principals are the operational backbone of vendor integrations in Azure and Microsoft 365 environments , and increasingly in AWS and GCP as well, under equivalent constructs like IAM roles for applications and GCP service accounts. Every vendor integration that operates programmatically in your environment does so through an identity of this kind. That means the governance of these identities is not an identity management edge case , it is the primary mechanism through which vendor access to your cloud tenant is exercised on a day-to-day basis.

The third-party risk implication is that a vendor's security posture, as assessed through their questionnaire and attestations, tells you nothing about what their service principal can do in your tenant. A vendor with excellent internal security controls, strong identity governance, and a clean SOC 2 report can still have a service principal in your Azure environment with Contributor-level access and a two-year-old client secret that has never been rotated. Those two facts are entirely independent. The vendor's internal controls govern their own environment. Your service principal governance governs yours , and in most organizations, that governance is absent.

From an attacker's perspective, vendor service principals are high-value targets precisely because they are persistent, automated, and broadly permissioned. An attacker who compromises the vendor's application server and extracts the client secret stored in its configuration file inherits everything that service principal can do in your tenant , immediately, silently, and using a credential that your identity protection controls are unlikely to flag because the authentication pattern looks identical to the application's normal behavior. There is no anomalous login location, no unusual device, no MFA bypass to detect. It is just the same service principal, authenticating the same way it always has, doing things it was never supposed to do.

Where most teams get this wrong

The most pervasive failure is excluding service principals from identity governance processes. Access reviews, privileged identity management programs, and offboarding checklists are typically designed around human users. Service principals appear in the same identity directory as human accounts but are consistently overlooked in governance workflows , either because the tooling filters them out, because reviewers do not know how to interpret them, or because ownership is ambiguous between the team that provisioned them and the vendor that uses them.

The second failure is the default credential expiry configuration. Azure AD client secrets can be created with expiry periods of up to two years , and many organizations accept the maximum expiry because shorter periods require more operational overhead to manage. A vendor service principal with a two-year client secret that is created at the start of an engagement and never reviewed has, by design, credentials that will remain valid for two years regardless of what happens to the vendor relationship in the interim. That is not a security default , it is a governance gap enshrined in configuration.

• Service principals excluded from access reviews because identity governance workflows are built around human users
• Client secrets created with maximum expiry , two-year validity periods that remain in force regardless of changes to the vendor relationship
• No owner assigned to vendor service principals , they are created by IT or engineering and never assigned to a named individual responsible for their governance
• Vendor offboarding processes that deprovision human accounts but do not audit or deactivate associated service principals
• No monitoring of service principal activity , authentication events, API calls, and resource access by vendor service principals not reviewed or alerted on

What good looks like

In well-governed environments, service principals associated with vendor integrations are treated as privileged identities subject to the same lifecycle management, access review, and monitoring obligations as human privileged accounts. They have owners, they have review cadences, they have defined expiry triggers, and their activity is part of the normal security monitoring picture , not invisible because they happen to be non-human.

• Named ownership for every vendor service principal , a specific internal individual responsible for monitoring, reviewing, and deprovisioning the identity
• Short-lived credentials as the standard , client secrets issued with 90-day maximum validity for vendor service principals, rotation automated or calendared before expiry
• Certificate-based authentication preferred over client secrets where operationally feasible , certificates are harder to exfiltrate and easier to revoke than secrets
• Service principals included in access reviews alongside human accounts , reviewed at the same cadence as privileged human identities with the same standard of justification required for continued access
• Sign-in and audit log monitoring configured specifically for vendor service principals , alerts on authentication from unexpected IP ranges, unusual API call volumes, or access to resources outside the normal operational pattern
• Deprovisioning checklists that explicitly include service principal deactivation , vendor offboarding is not complete until associated service principals are disabled and their credentials revoked

Tooling

Governing vendor service principals requires tools that extend identity governance beyond human users , a capability gap in many organizations' current tooling that is worth addressing specifically rather than assuming human-focused identity tools cover it.

Azure AD / Entra ID Governance , Microsoft Entra ID, Azure AD Access Reviews

Microsoft's native identity governance tooling supports access reviews that can be scoped to include service principals alongside human accounts. Entra ID Workload Identities , Microsoft's specific feature set for governing non-human identities , provides credential expiry management, usage analytics showing whether a service principal has recently authenticated, and risk scoring for workload identities showing anomalous behavior. For organizations with significant vendor integrations in Azure, Entra ID Workload Identities is the primary governance layer for service principal risk.

Cloud Entitlement Management , Authomize, ConductorOne, Tenable Cloud Security

These platforms provide unified visibility across human and non-human identities in cloud environments, including service principals, managed identities, and application registrations. They surface unused service principals, overprivileged roles, and credentials approaching expiry , the three most common service principal governance gaps , in a single dashboard. For TPRM practitioners, they provide the evidence base for demonstrating that vendor non-human identities are actively governed rather than passively inherited.

Secrets Management , HashiCorp Vault, Azure Key Vault, AWS Secrets Manager

For vendor service principal credentials specifically, secrets management platforms provide the rotation automation and audit logging that eliminates the manual overhead of credential governance. Rather than a static client secret stored in an application configuration file, a well-governed integration retrieves short-lived credentials from a secrets vault on demand , meaning the credential in use at any given moment has a short validity window and the vault maintains a complete audit trail of every retrieval. This model eliminates credential persistence as a risk factor.

Identity Threat Detection , Microsoft Sentinel, CrowdStrike Falcon Identity, Vectra AI

Detecting compromised service principal credentials requires monitoring that understands normal behavior patterns for non-human identities and flags deviations. Microsoft Sentinel's UEBA capabilities extend to workload identities, establishing behavioral baselines for service principals and alerting on anomalies , authentication from new IP ranges, access to resources outside the normal pattern, unusual API call volumes. For vendor service principals specifically, where the normal operational pattern is well-defined and constrained, behavioral anomaly detection is a practical and effective detection mechanism.

Governance challenges

The governance challenge with vendor service principals is that they inhabit a space between two teams that both consider them someone else's responsibility. Identity and access management teams govern human identities. Application and integration teams govern application configurations. Service principals associated with vendor integrations are identity objects that serve an application purpose , and in practice, they fall through the gap between those two ownership domains, managed by neither.

Closing this gap requires explicitly incorporating non-human identities into the identity governance framework , not as an extension of human identity governance but as a distinct category with its own governance requirements. The cadence, the evidence standards, and the revocation triggers for service principal governance are different from those for human accounts, and treating them identically produces either over-governance (reviewing application identities like user accounts) or under-governance (excluding application identities from review processes designed for users). A fit-for-purpose non-human identity governance framework addresses service principals on their own terms.

• Create a non-human identity register that includes all vendor service principals , identity name, associated vendor, permission scope, credential expiry, creation date, and named owner
• Set a maximum credential validity of 90 days for all vendor service principal client secrets , enforced by policy, with rotation automated or formally calendared
• Include service principal review in vendor risk reassessments , every vendor reassessment should confirm that associated service principals are still required, still appropriately scoped, and still actively governed
• Require vendor notification before creating new service principals or modifying existing ones in your tenant , treat service principal changes as governance events, not routine operational activity
• Audit service principal activity quarterly at minimum , authentication frequency, resources accessed, and any deviations from the expected operational pattern

If you are a small team

Start with a service principal inventory. Pull every service principal in your Azure AD or equivalent identity platform and cross-reference against your current active vendor relationships. For each service principal associated with a vendor, record the permission scope, the credential expiry date, and the last authentication date. That exercise will immediately surface three actionable categories: service principals associated with ended vendor relationships that should be deactivated, service principals with credentials approaching or past expiry that need rotation, and service principals with no recent authentication that may no longer be in active use.

• Use Azure AD's built-in reporting to list all service principals, filter for vendor-associated ones, and review their last sign-in date , anything with no sign-in in 90 days is a candidate for deactivation
• Check credential expiry dates for all active vendor service principals , any secret expiring within 30 days needs immediate rotation coordination with the vendor
• Add service principal deactivation to your vendor offboarding checklist as an explicit, confirmable step with a named owner
• Set a quarterly calendar reminder to review all vendor service principal activity logs , 30 minutes per quarter prevents years of governance debt

What to require

Ask directly:

"What service principals, application registrations, or equivalent non-human identities does your application or service use to access our environment, and what specific permissions does each one require?"

"How do you manage the credentials associated with those identities , specifically, what is your rotation policy for client secrets or certificates, and where are those credentials stored within your own systems?"

"What is your process for deactivating service principals and revoking their credentials when an integration is decommissioned or a contract ends?"

Expect as evidence

• A specific list of service principals used in your environment with their permission scopes described
• A credential rotation policy with a defined maximum validity period , ideally 90 days or less for client secrets
• Evidence of secure credential storage on the vendor side , a secrets vault, not a configuration file or environment variable
• A defined decommissioning process that includes service principal deactivation as an explicit step

A vendor who responds to the service principal question with 'our application handles the authentication automatically' has described how it works, not how it is governed. Press for the governance answer , who manages the credentials, how often they rotate, and what happens to them when the engagement ends.

How to evidence it

Non-human identity governance is an emerging but increasingly standard area of examination in cloud security assessments and identity-focused audits. Demonstrating due diligence requires evidence that vendor service principals are actively governed , inventoried, reviewed, monitored, and deprovisioned , not simply present and operational.

• Non-human identity register with vendor service principals documented including permissions, credential expiry, and named owners
• Access review records demonstrating service principals are included in periodic identity governance reviews
• Credential rotation records confirming vendor service principal secrets are rotated on the defined schedule
• Sign-in and activity log records demonstrating service principal behavior is monitored
• Offboarding records confirming vendor service principals were deactivated at contract termination

Key Takeaway

A vendor service principal is a permanent resident of your cloud tenant , it does not leave when the project ends, it does not forget its credentials when the relationship changes, and it does not raise its hand when it is doing something it should not. It authenticates silently, continuously, and with full authorization, until someone explicitly tells it to stop. Most organizations have more of these than they know about, with broader permissions than they remember granting, holding credentials that have never been rotated, doing things nobody is watching. The service principal is not the problem , the absence of a governance framework that treats non-human vendor identities as privileged assets is. Build the framework before you need it. You already have the exposure.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations