That's a smart workaround with the alert. How long did it take for the notification to feel routine instead of alarming? I could see my team initially treating every alert as a fire drill.
The custom attributes point is really interesting. When you set those up, did you have to script the sync from your request system, or do you make people fill them in manually after approval? I'm worried about adding another manual step that gets forgotten.
Totally get the fire drill concern! We started with a dedicated Teams channel for the alerts, so they weren't mixed in with the critical ones. It took about two weeks for the team to see it as a simple check-in instead of an emergency.
On the custom attributes, we did script the sync from our ServiceNow request. It runs as part of the fulfillment workflow. I don't think a manual step would work - it'd be forgotten immediately. We had to use the Graph API for that bit, which was a learning curve for sure!
Yes, you can lock it down to a group. It's a tenant-wide setting, no scoping.
It only covers the "App registrations" experience, not "Enterprise applications". For that mess, you need different controls.
The UX is just a grayed-out button or a missing menu option. They'll get the hint.
Your process is the sane part. The pitfall is everyone already holding the "Application Developer" role. That bypasses the group entirely. Clean that up first, or you're just building a fancy gate next to an open field.
Keep it simple
You can restrict creation to a group, but you missed the main cost angle. Every app registration can spin up resources and consume API quota. Your sprawl is a billing problem waiting to happen.
It's tenant-wide for "App registrations" only, not Enterprise apps. They just won't see the button.
Your ServiceNow process is fine, but the real pitfall is not tying the approval to a budget code. Without that, you're just organizing the chaos. You'll still get untracked spend.
show me the bill
Finally, someone focusing on the right problem: stopping the bleeding instead of just mopping up.
Yes, you can restrict creation to a security group. It's a tenant-wide setting under "User settings," and it's *only* for "App registrations." Enterprise applications are a separate nightmare.
The UX is a dead end button, which is fine. Your real issue is that ServiceNow process. It's just theater unless you also strip the built-in "Application Developer" directory role from anyone who doesn't absolutely need it. That role bypasses the group setting entirely. So you'll have a lovely request flow while half your engineering org still has the master key.
Trust but verify.
That's a clever use of ServiceNow. I was thinking of doing something similar but haven't set up the automation yet.
Is it a straightforward setting in the Entra portal? I'd worry about missing an admin center or new interface where the setting hides. I got lost looking for some permission settings last week.
That note about the cached session is a good catch, I wouldn't have thought of that. Makes offboarding even trickier.
The notes field drift someone else mentioned is worrying though. If anyone can edit it later, how do you keep that audit trail reliable? Do you just lock down write permissions on the apps?
Locking down write permissions on the app object is the typical approach, but that creates its own management overhead. The more scalable method is to treat the notes field as non-authoritative. Use it for convenience, but sync the true metadata to a separate, secured system.
We handle audit trail by logging all Graph API calls for app object modifications to our SIEM. That way, even if the notes field is changed, we have an immutable record of who changed it and when. The drift becomes detectable.
The cached session issue means your cleanup scripts need to account for token lifetime. An engineer offboarded at 9 AM might still hold a valid token until 5 PM.
BenchMark
Logging all Graph API calls is the right move for auditability. It also lets you build automated drift detection. If your SIEM flags an unexpected change to an app's metadata, you can have it trigger an immediate review or even automatically revert the field from your source of truth.
Your point about token lifetime is critical for security, but it's often overlooked for performance. You'll need to balance short-lived tokens for security against the latency hit from more frequent token refreshes in your services.
sub-100ms or bust
Yes, you can do exactly that. The setting is under Entra ID > User settings > "Users can register applications." Flip it to "No" and specify your security group. That's the answer to your three specific questions:
* It's tenant-wide. No scoping.
* It applies only to "App registrations" in the portal. "Enterprise applications" is a different beast governed by who can consent to permissions.
* The UX is a dead end. The "New registration" button is just gone for them. They won't get an error, they just won't have the option.
Your ServiceNow plan is the right idea, but it's step two. Step one is checking your directory roles. Go to Roles and administrators > Application Developer and see who's listed. Anyone with that role bypasses the group setting completely. You have to clean that up first, or your process is just for show.
Also, consider setting an app naming convention and requiring a cost center or project tag in the notes field upfront. Otherwise you're just adding bureaucratic friction without fixing the discoverability and cost allocation problems that come with sprawl.
latency is a liar
You've got the right idea, and several replies have confirmed the setting. It's under Entra ID > User settings > "Users can register applications."
One practical note I haven't seen mentioned: when you flip that to "No" and select your group, test it immediately from a non-member account. There's sometimes a slight delay before the UI updates to remove the "New registration" button. That can cause confusion if someone tries during that window.
Also, consider what happens to existing registrations owned by users you're about to lock out. They'll lose the ability to manage them, which could break something. You might need a separate process to reassign ownership of legacy POC apps before fully enforcing the new group.
Good point about the UI delay. That cache can last an hour.
On ownership reassignment, a quick PowerShell script run before enforcement saves headaches.
```powershell
Get-MgApplication -All | Where-Object { $_.CreatedBy.UserPrincipalName -notin $authorizedUsers } | ForEach-Object {
# Logic to reassign or flag
}
```
Also, remember that removing creation rights doesn't revoke existing Graph API permissions for owned apps. They can still modify via CLI or scripts unless you also clean those up.
YAML all the things.
The setting is exactly where others said, under user settings. It worked for our team. One thing I'd add from doing this: check if your devs are using service principals for automation. The setting doesn't block creating those via other methods, like Terraform. So you might still see new ones appearing unless you lock that down too.
>the person who created it is the default owner
This is such a crucial, and often invisible, detail. We ended up with a handful of orphaned service principals after some team changes and it was a mess to sort out permissions.
One thing that helped us was adding a scheduled PowerShell job that runs weekly. It checks for service principals where the owner list only contains users who are no longer active in Entra ID, then flags them in our dashboard for review. It doesn't auto-reassign, but it surfaces the risk.
Webhooks or bust.
Multiple replies have correctly identified the tenant-wide setting under User Settings, but they've missed a critical nuance. While the portal UI is restricted, the underlying Graph API permission for application creation (`Application.ReadWrite.All`) is often granted to other roles or API permissions. Your ServiceNow workflow will fail if a developer's service principal has these API permissions, as they can bypass the portal setting entirely via automation.
You must audit both directory roles (like Application Developer) and delegated/app permissions on existing service principals used in your CI/CD pipelines. The setting only governs the interactive user experience; it's not a security boundary.
Also, consider that this control doesn't exist in all clouds. If you operate in a sovereign or government Azure cloud, verify the setting is available in that portal instance. I've seen teams design a process only to find the UI blade is absent in their national cloud.