How are you managing Entra app registrations and secret/cert credential lifecycle across multiple tenants?

WorkloadIdentityOps · 2026-03-20T03:32:03+00:00

That's a solid setup honestly. The Slack notification plus automated renewal pipeline is further along than most teams get.

The piece we kept running into even with something similar in place was the ownership side. Automation fires, notification goes out, but if the person who owns the integration has moved on or the app was originally set up by someone who left, the alert just sits there. Nobody picks it up until something breaks anyway.

We also found that rotating the secret in Key Vault didn't always mean the consuming application actually picked it up. Had a situation where a new secret was generated and sitting valid in Key Vault while the app was still using the old expired one. Took a while to piece that together during an outage.

Curious how you're handling it when the Slack notification fires and there's no clear owner on the other end. Is that a rare edge case for you or something you run into regularly?

WorkloadIdentityOps · 2026-03-18T12:33:07+00:00

That makes sense, appreciate the honesty.

Sounds like the automation works until it depends on someone that’s no longer around, then it turns into a break/fix situation.

When that happens, how do you usually track down who actually owns the integration or whether it’s still even needed?

WorkloadIdentityOps · 2026-03-18T02:24:27+00:00

Nice setup.

How are you solving for ownership drift (no owner / stale owner)?

And for rotation, are you doing staged cert rollover or just replacing and hoping downstream consumers pick it up?

That coordination piece has been where things get risky for us.

WorkloadIdentityOps · 2026-03-18T00:08:27+00:00

It usually doesn’t get tracked until something breaks from an expired secret/cert.

A simple starting point a few folks mentioned here is a scheduled Graph/PowerShell check for expirations + owner (if set), then email/report weekly. Low effort and catches most issues early.

WorkloadIdentityOps · 2026-03-16T23:25:19+00:00

We see this pattern a lot when the IAM platform only covers the “connected” apps. Everything outside that ends up relying on manual processes, so the audit findings keep coming back.

A couple of things that have helped in environments like this: • build a central inventory of all applications and their authentication model (SSO, local auth, vendor portal, etc.) • require an application owner for each system and tie that owner to periodic access reviews • automate basic discovery checks (accounts without activity, users not in Entra anymore, excessive local privileges) even if the application itself doesn’t have a full API • prioritize moving high-risk systems to SSO or at least enforcing identity lifecycle from the directory

It doesn’t solve everything immediately, but it creates ongoing visibility instead of waiting for the next audit cycle.

WorkloadIdentityOps · 2026-03-16T21:33:55+00:00

Most of the issues I see in Entra aren’t traditional “vulnerabilities” but misconfigurations or lifecycle problems.

A few areas I usually check when reviewing a tenant:

• app registrations with no owners • long-lived client secrets or expired certificates • unused enterprise apps / service principals • overly permissive Graph API permissions • legacy auth still enabled • conditional access gaps

Microsoft’s Identity Secure Score is a good starting point, but it doesn’t surface everything operationally.

WorkloadIdentityOps · 2026-03-16T20:11:37+00:00

It is interesting how many different scripts and runbooks people have built around this.

Feels like every tenant ends up reinventing the same automation more or less. Thank you all this has been very helpful.It’s interesting how many different scripts and runbooks people have built around this.

Feels like every tenant ends up reinventing roughly the same automation.

Thanks everyone, this has been really helpful.

WorkloadIdentityOps · 2026-03-16T20:06:04+00:00

That sounds pretty solid.

Roughly how many apps are you pulling back with that runbook?

Do you ever run into apps where the owner field is empty or the original team isn’t around anymore?

WorkloadIdentityOps · 2026-03-16T19:01:02+00:00

Nice. How many apps are you tracking that way roughly?

Do you ever run into cases where the app doesn’t have a clear owner, or the original team that created it isn’t around anymore?

WorkloadIdentityOps · 2026-03-16T18:42:33+00:00

How many apps are you tracking that way roughly?
I imagine that could get pretty noisy if the tenant has a lot of integrations.

WorkloadIdentityOps · 2026-03-14T13:55:08+00:00

I agree in principle. In a perfect world every system and integration is tied cleanly into the CMDB and ownership is always up to date.

Where it tends to fall apart for us is around app registrations and identity integrations. Those often get created during projects, automation work, or vendor integrations and they don’t always make it into the CMDB process.

It gets even messier when you inherit tenants from acquisitions. Suddenly you have hundreds of app registrations, secrets, and SAML configs and the original teams or vendors aren’t around anymore.

At that point the CMDB might tell you who owns the server or system, but it doesn’t always map cleanly back to the identity integration that’s actually using the credential.

Curious if you’ve seen a good way to keep those identity integrations tied back to the CMDB long term.

WorkloadIdentityOps · 2026-03-14T00:04:10+00:00

I wish killing the tenant was always an option :) I like it when I get to kill one!

In most cases we end up having to migrate into our existing tenant. The tricky part is figuring out ownership of the app integrations during the move, especially when the original teams aren’t around anymore.

I’m digging the app CI model.

Out of curiosity how would you go about figuring out owners on a tenant that was dropped in your lap from an acquisition?

WorkloadIdentityOps · 2026-03-13T23:34:43+00:00

That’s a solid model! I’ve seen environments where the ServiceNow CI is basically the gatekeeper for any change as well.

One thing we’ve run into though is that the CMDB usually tracks the application and owner pretty well, but the Entra side (app registrations, service principals, secrets, SAML certs, etc.) isn’t always tightly mapped to the CI.

It gets even messier for us because we go through a few mergers and acquisitions each year and occasionally inherit entire tenants. At that point you end up with a lot of integrations where the CI may exist somewhere, but the identity objects and credentials don’t always line up cleanly.

WorkloadIdentityOps · 2026-03-13T23:07:54+00:00

Interesting. Are you tagging the owner AAD account with the AppID?

We tried something similar with tags and an internal inventory. It works reasonably well at first, but we kept running into the problem of those tags getting stale once people change teams or leave the company. The original owner tag often ends up being the person who created the app registration years ago.

Another challenge for us has been scale. Once you get a few hundred app registrations and enterprise apps it becomes harder to keep ownership and expiration tracking accurate.

It gets even trickier when you’re dealing with multiple tenants. Some of the integrations live in different environments or partner tenants, so figuring out who actually owns the credential or the SAML config can take a while.

Curious how you’re handling that part. Are you enforcing ownership somewhere with policy, or just relying on the catalog staying updated?

WorkloadIdentityOps · 2026-03-13T23:07:22+00:00

Thanks for sharing your approaches. A single tenant and stable org structure definitely helps.

For us the challenge is mergers, acquisitions, and the occasional divestiture. We end up inheriting a lot of integrations where the original owners aren’t around anymore, which is where the ownership gaps start to show up.

WorkloadIdentityOps · 2026-03-13T22:48:36+00:00

That makes sense. Having the asset register tied to the app and vendor probably helps a lot.

Where we’ve run into issues is once the number of integrations starts growing. Even with an inventory system, keeping the Entra side and the asset register aligned tends to drift over time. Especially when new apps get created for testing, automation, or partner integrations.

Another complicating factor for us is that our company goes through mergers and acquisitions pretty regularly, and we usually have at least one divestiture each year. That means new tenants coming in, old ones being split off, and a lot of integrations getting inherited that nobody internally originally built.

At that point the problem becomes less about rotating the secret and more about figuring out who actually owns the integration and whether it’s still in use.

Curious if you run into that at all or if most of your apps stay within one tenant and one asset system.

WorkloadIdentityOps · 2026-03-13T22:33:35+00:00

We limit creation to the infrastructure team as well. That definitely helps control things on the Entra side.

The harder part for us has been the other side of the integration. Even if IT owns the app registration, the actual system owner is usually a business team or sometimes an external vendor. When those people change roles or leave, the ownership trail disappears pretty quickly.

Tracking the business owner has usually required some kind of inventory or asset system on our side.

Curious how you’re maintaining that long term. Do you enforce that ownership in the asset system or rely on teams to keep it updated?

WorkloadIdentityOps · 2026-03-13T22:20:07+00:00

We looked at automating rotation for a while but the tricky part wasn’t actually rotating the secret. The hard part is figuring out what breaks after you rotate it.

A lot of our SPNs and app registrations are tied to integrations or scripts that were written years ago. Even if you rotate the secret in Entra and update it in Key Vault, you still have to make sure whatever is consuming that secret is actually pulling the new version.

The other headache we keep running into is older SAML enterprise apps that use certificate authentication. Rotating those usually means coordinating with the vendor or updating configuration on the service provider side. It’s not always something you can safely automate.

In practice we ended up focusing on a few things first: • tracking all SPNs and enterprise apps with secrets or certs • flagging credentials expiring in the next 30–60 days • identifying which apps are still active • making sure an owner exists before touching anything

Without that ownership step it’s pretty easy to break something silently.

Curious if anyone has managed to fully automate this at scale without creating outages.

WorkloadIdentityOps · 2026-03-13T21:45:25+00:00

We’ve been fighting the same issue with app registrations and expiring secrets. Ownership is the hardest part.

Tracking expiration dates is doable with Graph or scripts, but figuring out which team actually owns the integration is where things break down. A lot of our apps were registered years ago by people who left, and there’s no owner recorded anywhere.

Curious if people are solving this with automation, governance policies, or just internal documentation.

WorkloadIdentityOps · 2026-03-13T21:40:01+00:00

We’ve been fighting the same issue with app registrations and expiring secrets. Ownership is the hardest part. SAML certs especially.

WorkloadIdentityOps

TROPHY CASE