What breaks when access requests are handled through email and chat?

Why This Matters for Security Teams

Email and chat are built for conversation, not authorization. Once access requests move into informal channels, the organisation loses the basic controls needed to verify requester identity, confirm approver authority, and preserve an immutable record of what was approved. That creates a gap between intent and enforcement, which is exactly where privilege creep and undocumented exceptions begin.

This is not just a workflow issue. It affects auditability, separation of duties, and incident response. The OWASP Non-Human Identity Top 10 is clear that unmanaged identity paths and weak credential handling create repeatable exposure patterns, and the same logic applies when humans approve access through side channels instead of governed systems. NHIMG’s Ultimate Guide to NHIs also shows that identity sprawl becomes harder to contain once approval evidence is scattered across inboxes and message threads.

In practice, many security teams encounter excessive access only after an incident review reveals that the original approval lived in a chat transcript no one could validate.

How It Works in Practice

When access requests are handled in email or chat, the organisation usually relies on manual interpretation: someone asks for access, a manager replies “approved,” and a privileged administrator makes the change later. That process breaks down because the approval is detached from policy enforcement. There is no guaranteed link between the request, the approver, the resource, the duration, and the actual entitlement granted.

For security teams, the practical control objective is to move approvals into a system that can record context at the moment of decision. Current guidance from OWASP Non-Human Identity Top 10 and the NHI research in 52 NHI Breaches Analysis both point to the same operational truth: if approvals are not tied to identity, scope, and expiration, the resulting access becomes difficult to govern after the fact.

• Require requests to flow through a ticketing or IAM workflow that captures requester, approver, resource, justification, and time.
• Bind approvals to policy checks so privileged access cannot be granted outside defined roles, durations, or business context.
• Use time-limited elevation or just-in-time access where possible, so approvals expire automatically.
• Preserve an audit trail that shows who approved, what was approved, and when it was revoked.

For environments that also manage automated workloads, the same discipline should extend to machine identities and secrets, because informal approval paths often lead to long-lived exceptions that outlive the original need. These controls tend to break down when approvals are copied into message threads during incident response or after-hours operations because the final entitlement often differs from the request that was originally written.

Common Variations and Edge Cases

Tighter approval workflow controls often increase operational friction, requiring organisations to balance speed against accountability. That tradeoff is real in service desks, emergency maintenance, and small teams where people expect fast decisions. Current guidance suggests that the answer is not to abandon governance, but to define narrow exceptions with stronger logging and explicit expiry.

There is no universal standard for every exception path yet, but best practice is evolving toward policy-driven approvals, temporary elevation, and post-action review. In high-pressure environments, email may still be used to notify stakeholders, but not to serve as the source of record. Chat may help coordinate response, but it should not be the system of approval.

NHIMG’s The State of Secrets in AppSec is relevant here because weak operational discipline often accompanies weak entitlement hygiene, especially when teams are already managing fragmented control points. The same pattern appears in the DeepSeek breach, where exposed sensitive material showed how quickly undocumented handling can escalate into broader risk.

Exception handling is the edge case that matters most: if an organisation allows “temporary” access by email during outages, that temporary state often becomes the default unless it is deliberately reviewed and revoked.

Related resources from NHI Mgmt Group

• What breaks when access requests are handled like ordinary support tickets?
• What breaks when mid-lifecycle access changes are handled through tickets only?
• How should security teams govern access requests through IT service management tools?
• What breaks when access relationships are only reviewed through spreadsheet exports?