Entra Security Settings

These foundational security settings in Microsoft Entra ID (formerly Azure AD) establish the "guardrails" for user autonomy and application integration. They enforce the principle of least privilege (NIST SP 800-171 3.1.5) and prevent unauthorized system access (3.1.1) across all regulated environments.

3.2.1.1 User | User settings

In a regulated environment, users should have the minimum permissions necessary to perform their jobs. Unrestricted access to the administration portal or the ability to create new tenants can lead to "shadow IT" and undocumented compliance boundaries.

Setting	Recommended Value	Rationale
Restrict access to Microsoft Entra administration portal	Yes	Hides a set of admin center pages from non-administrators; Learn calls it "not a security measure." Deep links still open most pages, and Graph, PowerShell, and other clients read the directory as before. To block non-administrators from Azure management endpoints, use a Conditional Access policy targeting Windows Azure Service Management API; to stop them reading other users, set allowedToReadOtherUsers to false on the authorization policy (Graph or PowerShell only; it also affects people pickers in Teams and Outlook).
Restrict non-admin users from creating tenants	Yes	Prevents users from spinning up unauthorized, unmanaged Entra tenants using corporate credentials, which creates an immediate compliance boundary violation.
Users can create security groups	No	(Environment dependent) Restricting group creation to admins or an automated governance process ensures that the RBAC model remains clean and auditable.
Users can create Microsoft 365 groups	No	Prevents the sprawl of unmanaged Teams and SharePoint sites, which often become undocumented repositories for sensitive data.

---

3.2.1.2 Enterprise applications | Consent and permissions | User consent settings

User-led consent can grant an unvetted application delegated access to organizational data. MFA does not make an authorized application trustworthy: after consent, an app can use tokens within its granted permissions. Conditional Access still applies to the relevant sign-in and resource flows; consent is not a universal bypass. Review permissions, publishers, and ongoing application access.

Setting	Recommended Value	Rationale
User consent for applications	Do not allow user consent	Recommended baseline for this guide: route new consent requests through an admin review. Review existing grants separately; changing this setting does not revoke them. This is an architecture recommendation, not a universal GCC High service requirement.
Group owner consent for apps accessing data	Do not allow group owner consent	Prevents Team/Group owners from bypassing IT governance by authorizing "bots" or "reporting tools" that may exfiltrate data from specific SharePoint sites or Teams channels.

---

3.2.1.3 Enterprise applications | Consent and permissions | Admin consent settings

Disabling user consent requires a formal process for users to request the applications they need. The Admin Consent Workflow provides this "front door," creating an auditable request-and-approval trail for every integrated application.

Setting	Recommended Value	Rationale
Users can request admin consent to apps they are unable to consent to	Yes	Provides a structured way for users to request new tools without resorting to insecure workarounds.
Admin consent request reviewers	Select 2-3 Admins	Assign specific Global Admins or Cloud Application Admins to receive and vet requests.
Selected users will receive email notifications for requests	Yes	Ensures timely review of application requests to minimize productivity friction.
Selected users will receive request expiration reminders	Yes	Prevents requests from languishing and ensures the governance process remains active.

Compliance Evidence

The Admin Consent Workflow supports AC.L2-3.1.1 (authorized users and processes) and AC.L2-3.1.2 (authorized transactions and functions), and its approval record is the evidence for CM.L2-3.4.9 (User-Installed Software; folded into 3.4.8 in Rev 3) for cloud applications. It does not satisfy AC.L2-3.1.22, which covers content posted on publicly accessible systems. Keep the request and decision history (Enterprise apps > Admin consent requests > All) and a periodic export of granted permissions as evidence.