An app registration is the application object that defines an app in Microsoft Entra ID and holds its credentials (client secrets, certificates, and federated identity credentials); it lives in the tenant that published the app, which for vendor apps is not yours. Registering an app creates one globally unique application object in the home tenant plus a globally unique app (client) ID. That object describes three things: how the service can issue tokens for the application, the resources the application might need to access, and the actions it can take. It is a template; the object that actually signs in and holds permissions in your tenant is the service principal created from it.
Why it matters to a lean team
The app registration is where credentials live. A client secret or certificate on the registration is what lets the app obtain tokens, with every permission its service principal has been granted and no user sign-in involved. Microsoft says client secrets are less secure than certificates or federated credentials and should not be used in production; it caps secret lifetime at 24 months and recommends less than 12. The secret value is shown once and never displayed again. For a team of one to five people this is the quiet part of the estate: registrations are created by developers and consultants, outlive their projects, and keep working after the person who made them has left.
Two details trip up incident work. Deleting the application object deletes the service principal in the home tenant, but restoring the application through the App registrations page does not restore the service principal. And for a vendor's multitenant app, the registration sits in the vendor's tenant; you only ever see the service principal it produced in yours.
How it shows up in Entra ID
- Admin center. The App registrations page lists the application objects registered in your tenant. The Enterprise applications page lists service principals, including their permissions, who consented, and sign-in information. Registering through the admin center creates both objects at once.
- Microsoft Graph. The registration is the
applicationresource; its counterpart is theservicePrincipalresource. When you create an application through Graph, creating the service principal is a separate step. - Credentials. A confidential client can carry three credential types on the registration: client certificates, client secrets, and federated identity credentials. Certificate uploads accept .cer, .pem, or .crt files.
- Consent. Granting certain application permissions requires a more privileged administrator, such as a Privileged Role Administrator, even when the registration itself requested them.
What to do about it
- Inventory registrations and their credentials. Microsoft's remediation guidance starts by inventorying all credentials on both the service principal and the application object. Do this before an incident, not during one. Our guide on finding expiring client secrets in Entra ID covers the query.
- Move production apps off secrets. Microsoft recommends a certificate rather than a client secret before an app goes to production, ideally a CA-signed certificate managed in Azure Key Vault, with self-signed certificates for testing only. Where the workload can use it, workload identity federation removes the stored secret or certificate altogether.
- Keep secret lifetimes short. Under 12 months, per Microsoft.
- Check what the service principal can reach. A registration is only as dangerous as the permissions and roles on its service principal. See service principals with Global Administrator and the Directory.ReadWrite.All entry.
- If you suspect compromise, follow Microsoft's steps: inventory all credentials on both objects, add a new credential (x509 certificate recommended), remove the compromised credentials (all of them if the app is believed at risk), and rotate any Azure Key Vault secrets the service principal can reach. Deactivating the app stops new token issuance while preserving both objects for investigation.
Where Orbitra fits
Orbitra maps human and non-human identities (service principals, app registrations, OAuth grants, managed identities) in one graph with blast radius traversal, so a registration appears beside the service principal it produced and what that principal can reach, and roughly 40 percent of its deterministic detection rules target applications, service principals, consent grants, and app credentials. When a credential has to go, the response comes from an allowlisted catalog of more than two dozen governed response actions, and Orbitra independently re-reads Microsoft after supported response actions to verify the final state. In Recommend mode, your team executes the response; in Approve mode, a named person signs off before Orbitra executes. Connect Microsoft in minutes and start read-only.
Related terms
Sources
- Application and service principal objects in Microsoft Entra ID (Microsoft Learn, checked September 2026)
- Add and manage application credentials in Microsoft Entra ID (Microsoft Learn, checked September 2026)
- Workload identity federation (Microsoft Learn, checked September 2026)
- Securing workload identities with Microsoft Entra ID Protection (Microsoft Learn, checked September 2026)
- Microsoft Entra built-in roles (Microsoft Learn, checked September 2026)