GitHub announced on September 15, 2026, that enterprise security configurations can enforce the enablement status of selected security features across organizations and repositories. The change gives enterprise administrators a way to prevent lower-level administrators from changing settings that a configuration explicitly enables or disables.
The control is aimed at teams managing security standards at scale. It can cover settings related to code security, secret protection, code scanning, dependency management, Dependabot, and private vulnerability reporting. However, the available controls depend on the GitHub security products and licensing arrangements in use, and the announcement does not establish universal availability for every Enterprise Cloud account.
What changed
An enterprise-level security configuration now provides three enforcement choices:
- Don’t enforce: The configuration does not prevent lower-level administrators from changing controlled feature states.
- Enforce for repository owners: Repository owners cannot change the enablement status of features controlled by the configuration.
- Enforce for repository and organization owners: Neither repository owners nor organization owners can change those controlled feature states.
At the organization level, enforcement applies to repository owners. The distinction matters for enterprises where organization administrators manage repositories on behalf of multiple teams. Selecting the broader enterprise scope extends the restriction to both organization and repository owners.
Enforcement applies only to settings that the configuration explicitly enables or disables. A feature left unset is not enforced. This makes the configuration more precise than a general claim that every available security control will be centrally locked.
The GitHub enforcement documentation describes the administrative behavior and conditions that can prevent enforcement from being maintained.
Which security settings are covered?
The documented configuration controls include GitHub Code Security or Secret Protection, secret-scanning options, code-scanning default setup and runner options, the dependency graph, automatic dependency submission, Dependabot alerts and security updates, and private vulnerability reporting.
The REST API exposes configuration fields for areas such as advanced_security, code_security, dependency_graph, Dependabot, code scanning, secret scanning, private vulnerability reporting, and enforcement. The exact controls visible to an organization can vary according to the products and licensing model it uses. Some Code Security or Secret Protection features can incur usage costs or require GitHub Advanced Security licensing for private and internal repositories.
Administrators should therefore treat a configuration as a defined set of selected controls, not as an automatic guarantee that every security feature is enabled everywhere.
How configuration status affects operations
GitHub documents several statuses for security configurations: attached, attaching, updating, enforced, removed, removed_by_enterprise, failed, and detached. An enforced configuration is actively applied, and repository administrators cannot change the enablement status of features controlled by it.
Other statuses are important during rollout and troubleshooting. A repository can enter a removed or failed state when its settings conflict with a configuration. An enterprise-level change can also produce a removed_by_enterprise status. These states mean administrators should verify the resulting configuration rather than assume that selecting enforcement has produced complete coverage.
The enforcement documentation identifies several conditions that can break enforcement. They include disabled GitHub Actions, Actions required by a code-scanning configuration that are unavailable, and changes to the languages excluded from code-scanning default setup. Teams using those features should validate their prerequisites before applying a centrally enforced configuration.
Implications for API automation
Enforcement changes the expected behavior of repository-level automation. A REST API request that attempts to change the enablement status of a feature in an enforced configuration may appear to succeed while leaving the actual status unchanged. Automation should therefore check the resulting configuration state instead of relying only on the response from the write operation.
The REST API documentation covers enterprise code-security configuration management and related configuration fields. Listing and creating enterprise configurations require enterprise-administrator authentication. The documentation also specifies endpoint-specific OAuth or classic personal access token scopes and excludes certain token types for those endpoints.
Creating a custom organization security configuration has a different administrative model. The supplied organization configuration guide documents that organization owners, security managers, and organization members with the admin role can create one. Teams should distinguish those organization permissions from the enterprise administrator requirement for enterprise configuration API operations.
What administrators should do
- Inventory the intended controls. Review each security feature in the configuration and identify whether it is explicitly enabled, explicitly disabled, or left unset. Only the first two states are subject to enforcement.
- Choose the governance boundary. Decide whether the policy should restrict repository owners only or both repository and organization owners. Use the no-enforcement option when the configuration is being evaluated without imposing that restriction.
- Check existing conflicts. Review organization and repository settings before applying the configuration. The documented statuses include removed, removed_by_enterprise, and failed states for conflicts, and the supplied material does not establish that every existing deviation is automatically remediated.
- Validate prerequisites. Confirm that GitHub Actions is available and that any Actions required by code scanning can run. Also review code-scanning language exclusions before enforcing a configuration that includes default setup.
- Confirm licensing and costs. Check the applicable GitHub security products, licensing, and usage costs before enabling Code Security or Secret Protection features for private or internal repositories.
- Verify after changes. Use configuration statuses, the organization repository table, the REST API, and audit-log events to confirm that the intended state was applied.
Auditing and availability considerations
Configuration status changes generate repository_security_configuration events in the organization audit log. Administrators can search for those events with the action:repository_security_configuration filter through the organization interface or REST API. This provides a way to track configuration changes alongside status information shown in the organization repository table.
An organization’s default security configuration applies automatically to newly created repositories. Transferred repositories still require manual application according to the supplied configuration guidance. The available documentation does not define a universal automatic remediation process for every existing conflict or deviation.
GitHub’s announcement was published on September 15, 2026, and the supporting material is for GitHub Enterprise Cloud. The supplied sources do not confirm regional availability, staged rollout status, account eligibility, or universal general availability across all Enterprise Cloud accounts. They also do not provide a complete enterprise-level rollback procedure or fully define precedence for every combination of enterprise, organization, and repository configuration attachment. Those details should be confirmed in the relevant account documentation before a broad rollout.
For platform teams, the practical change is a stronger governance option: selected security enablement states can be centrally protected from lower-level edits. The safest rollout is to define the controlled settings, inspect current repository and organization states, validate dependencies, and monitor status and audit events after enforcement is applied.
Sources
- GitHub Changelog: Enforce GitHub Advanced Security configurations
- GitHub documentation: Configuration enforcement
- GitHub documentation: Security configuration statuses
- GitHub REST API: Code security configurations
- GitHub documentation: Create a custom security configuration
- GitHub documentation: Establish complete coverage
