Restrict who can register apps + consent to apps
Demonstrate that application registration and consent permissions are restricted to authorized roles, preventing standard users from creating or approving applications that could access organizational data or identities.
Description
What this control does
This control restricts which users or groups within an identity platform (typically Azure AD / Entra ID, Google Workspace, or Okta) can register new OAuth/OIDC applications and grant consent for applications to access organizational resources. It prevents unauthorized users from creating malicious applications that harvest credentials, exfiltrate data, or impersonate legitimate services. By limiting app registration and consent permissions to designated administrators or security-approved roles, organizations reduce the attack surface for OAuth abuse and shadow IT proliferation.
Control objective
What auditing this proves
Demonstrate that application registration and consent permissions are restricted to authorized roles, preventing standard users from creating or approving applications that could access organizational data or identities.
Associated risks
Risks this control addresses
- Malicious insiders register rogue OAuth applications to harvest user credentials or tokens through phishing-style consent prompts
- External attackers exploit compromised user accounts to register applications with persistent access to email, files, or identity data even after credential resets
- Users grant consent to unvetted third-party applications with excessive permissions, enabling data exfiltration to external services
- Shadow IT proliferates as business users deploy unauthorized SaaS integrations without security review, creating unmanaged data flows
- Illicit consent grants create persistent backdoors that remain active after initial breach remediation, enabling attacker re-entry
- Applications registered by departing employees persist with access to organizational resources due to lack of governance
- Consent phishing campaigns trick users into authorizing malicious applications disguised as legitimate productivity tools
Testing procedure
How an auditor verifies this control
- Export the identity platform's tenant-level settings for user application registration permissions (e.g., Azure AD portal 'Users can register applications' setting or equivalent).
- Review the consent policy configuration to identify which users or roles can consent to applications and under what conditions (admin-only, risk-based, delegated consent policies).
- Enumerate all custom roles or directory roles that include application registration or consent permissions (e.g., Application Administrator, Cloud Application Administrator).
- Select a sample of five standard non-administrative user accounts from different departments and business units.
- Attempt to register a test application using each sampled user account credentials or simulate the registration workflow to confirm denial.
- Review audit logs for the past 90 days to identify any application registrations or consent grants performed by non-authorized users.
- Interview identity platform administrators to confirm the business process for requesting application registration and consent approvals, including ticketing or change control workflows.
- Validate that documented procedures align with technical enforcement by cross-referencing approved application lists against logged registration events.
Where this control is tested