The usual outcome is that delegation has to be implemented through a controlled intermediary. Subsidiary administrators can maintain local account attributes, while a central provisioning process creates or removes mailboxes, sets address policies, and applies access rules. This preserves centralized security boundaries without forcing a full directory collapse or giving remote teams direct administrative authority.
How delegated control works when the parent keeps forest access closed
The practical answer is to separate ownership of the directory from ownership of the mailbox workflow. Subsidiary teams can manage local fields and request-driven updates, but the parent keeps the authoritative directory boundary intact. That usually means a central provisioning path, not direct forest access, handles mailbox creation, removal, policy assignment, and any changes that affect shared naming or security rules.
This approach is common when the organisation wants local operational autonomy without extending domain-level trust. It preserves a single control point for changes that can affect routing, compliance, and access enforcement, while still allowing subsidiaries to run day-to-day administration inside the guardrails that have been approved.
What the subsidiary can change, and what stays central
The split is usually functional rather than purely technical. Subsidiaries can often maintain employee attributes, department data, address details, and other local account metadata that drives email presentation or local processes. Central IT, or a controlled integration service, typically owns the actions that create the mailbox, apply address policies, set delegation rules, and decide whether an account is enabled, disabled, or remapped.
That division matters because email settings are not all equal. Some changes are low-risk presentation updates; others alter how messages are delivered, who can send as whom, whether a mailbox exists, or which access rules apply. Once a change touches those higher-impact areas, the organisation usually treats it as a governed provisioning event rather than a local administrative task.
Why the intermediary model is usually the right compromise
A controlled intermediary lets the parent company keep the forest boundary closed while still servicing subsidiary operations. In practice, that intermediary may be a provisioning workflow, a synchronisation job, or a managed service that accepts approved requests and applies them with centrally defined logic. The key point is that the subsidiary does not need direct administrative authority over the forest to keep its email records current.
From an operational perspective, this avoids the two extremes that usually cause trouble: either giving local teams too much control, or forcing them to wait on manual central intervention for every routine update. The intermediary model keeps approval, auditability, and rollback in one place, which is especially important when mailbox actions affect multiple systems or need to follow a consistent lifecycle.
Risk and Threat Considerations
The main risk is that delegated email administration can drift into excessive access if the boundary is not carefully defined. If subsidiary users can directly alter mailbox objects, group membership, or routing-related settings beyond their remit, the organisation can end up with inconsistent policy enforcement, privilege creep, and harder-to-audit changes.
Failure mechanism: Local convenience is allowed to bypass the central control point, so changes that should be authenticated, reviewed, and logged at the parent level are instead made from outside the governed process.
Impact: Misrouted mail, unauthorized access changes, address spoofing opportunities, and weak change traceability can follow, especially when multiple subsidiaries share the same messaging platform or policy namespace.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Mailbox provisioning depends on controlled credential and account lifecycle handling. |
| AC-6 — Least Privilege | Subsidiary admins need limited delegation, not direct forest authority. | |
| Recommendation — Manage mailbox account credentials through approved lifecycle controls and revoke them promptly on role change. Limit subsidiary administrators to the minimum permissions needed for local email data maintenance. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Closed-forest delegation is fundamentally an access-control design question. |
| Recommendation — Define and enforce who may request, approve, and execute mailbox changes across the boundary. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The model hinges on controlled administrative access and delegated change paths. |
| Recommendation — Review delegated email administration and remove direct access paths that exceed business need. | ||
Practitioner Guidance
What to verify: Confirm which settings are purely local metadata and which ones trigger central provisioning, because the safe boundary is defined by the mailbox action, not by the team making the request. Require a clear request path for any operation that changes identity, routing, delegation, or access state.
Decision rule: If a requested change can affect who receives mail, who can act on a mailbox, or whether a mailbox exists at all, treat it as a centrally governed change even when the subsidiary owns the user relationship. Keep local teams focused on request initiation and data maintenance, not on direct forest administration.
Practitioner takeaway: The best operating model is not “centralise everything” or “decentralise everything”, it is to centralise the irreversible mailbox controls and let subsidiaries manage the local data that feeds them.
Related resources from NHI Mgmt Group
- What happens when teams try to manage remote access without a central credential strategy?
- What happens when subsidiaries manage their own internet-facing assets without central visibility?
- What happens when organisations try to manage Office 365 identities and devices without a central identity and access platform?
- How should security teams run access reviews for non-human identities?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
