Who is accountable when a calendar system allows cross-account takeover through delegation controls?

Accountability sits with the platform owner and the security team that designed and validated the authorization model. Delegation features must be reviewed as access-control primitives, not convenience features. If a write path can alter proxy membership without ownership checks, the organisation owns the risk, the exposure, and the remediation.

Why This Matters for Security Teams

Delegation controls are not a convenience layer. They are an authorization boundary, and when that boundary can be altered across accounts, the question becomes one of control design and ownership, not user error. Security teams often miss that the risky path is usually the write action that changes proxy membership, not the eventual mailbox access itself. That is why cross-account takeover issues must be assessed like any other privilege-escalation path, with explicit validation and auditability. The broader NHI problem is well documented in NHIMG research, including the Ultimate Guide to NHIs, which notes that 97% of NHIs carry excessive privileges and 73% of vaults are misconfigured. When delegation is weak, those patterns become account compromise at scale.

Security teams should also map these controls to established authorization expectations such as NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access enforcement and account management overlap. In practice, many security teams encounter delegation abuse only after an attacker has already expanded from one account into another, rather than through intentional control testing.

How It Works in Practice

The accountable parties are usually the platform owner, the product security function that approved the model, and the team that operates the identity or mail service. If a calendar system allows one account to add delegates, modify proxy lists, or grant send-on-behalf permissions without strong ownership checks, that system has created a cross-account control plane. The right question is whether the authorization logic enforces who may delegate, under what conditions, and with what evidence. NIST guidance on access control and account management is helpful here, but it does not replace product-specific validation.

Practically, mature teams treat delegation as a privileged workflow with runtime checks, logging, and revocation. That means validating ownership before a delegate is added, requiring step-up authentication for sensitive changes, and alerting on abnormal delegation patterns. It also means reviewing whether service accounts, support tooling, or admin workflows can alter delegation state in ways ordinary users cannot see. The Ultimate Guide to NHIs — Standards is useful because it frames identity controls as lifecycle and governance issues, not just authentication events. For delegation abuse, the control question is simple: can the actor who changes the proxy list prove authority over the target relationship?

• Require ownership checks before delegation changes are accepted.
• Separate delegate management from normal calendar or mailbox operations.
• Log who granted access, who approved it, and when it expires.
• Revoke stale proxy relationships automatically and review standing delegates.
• Alert on privilege expansion across accounts, tenants, or organizational boundaries.

Controls like these tend to break down in legacy collaboration platforms and mixed-tenant environments because identity ownership, delegation logic, and audit logging are often implemented in different layers that do not enforce the same trust assumptions.

Common Variations and Edge Cases

Tighter delegation controls often increase operational overhead, requiring organisations to balance fast collaboration against stronger ownership validation. That tradeoff becomes harder in support desks, executive assistant workflows, and merger or partner-access scenarios, where delegation is operationally necessary but also highly abusable. Best practice is evolving, but there is no universal standard for this yet: some organisations allow temporary delegation with explicit expiry, while others require approval for every sensitive proxy grant.

Edge cases matter. Shared mailboxes, assistant workflows, and automation accounts can blur who the real owner is, especially when access is inherited through groups or nested roles. In those cases, incident response should ask not only who used the account, but who had authority to create or change the delegation path. NHIMG incident research such as the Meta AI Instagram Account Takeover shows how trust in a helper interface can turn into unauthorized access when control validation is weak. Organisations should also remember that delegation abuse is often a symptom of broader identity sprawl, as highlighted in the GitLocker GitHub extortion campaign, where over-permissive access paths and weak governance created room for escalation.

Accountability does not shift to the attacker just because a feature was exposed. If the system allowed the takeover path, the organisation is accountable for the design, the monitoring gap, and the remediation.

Related resources from NHI Mgmt Group

• Who is accountable when an OAuth login flow allows account takeover through weak redirect controls?
• Who is accountable when a cross-user authorization bypass allows integration takeover in an enterprise application?
• Who is accountable when a managed service vulnerability allows standard users to gain full SYSTEM access before the fix is applied?
• Who is accountable when a financial system accepts a compromised login and exposes sensitive account data?