Because they often store operational credentials needed by integrations, automation and support workflows. When tokens, API keys or service account details live in tickets or scripts, a compromise of the workflow platform can reveal reusable access material for downstream systems. That turns a support repository into a privilege-concentrating identity surface.
Why Service Desks Become an Identity Concentrator
Service desks and ITSM platforms are built to move fast: resolve incidents, provision access, coordinate automation, and capture operational context. That speed becomes risk when the platform starts storing API keys, service account passwords, session tokens, certificates, or runbook secrets. A ticketing system can quickly turn into a centralised repository of reusable access material, which is exactly the kind of concentration attackers look for.
The problem is not limited to careless note-taking. Integrations often need credentials to talk to cloud services, SaaS tools, monitoring systems, and CI/CD pipelines, and those secrets are frequently pasted into tickets, chat transcripts, or scripts so work can continue. Current guidance suggests that exposed secrets persist far too often; the Ultimate Guide to NHIs notes that 96% of organisations store secrets outside dedicated secrets managers in vulnerable locations, and 79% have experienced secrets leaks. In practice, many security teams discover this only after a support workflow has already become the easiest path into downstream systems, rather than through intentional design.
That pattern also aligns with broader incident trends described in the 52 NHI Breaches Analysis, where non-human identities repeatedly appear as the entry point to wider compromise. For an operational view of why this matters in modern identity programs, see the NIST Cybersecurity Framework 2.0.
How the Risk Shows Up in Real Workflows
The exposure usually develops through ordinary support mechanics. An agent requests access, a technician retrieves a token, a bot updates a system, or a script needs an API key to complete a task. If the service desk stores those values in ticket fields, attachments, comments, or knowledge articles, the ITSM platform becomes an indirect credential vault without vault controls. Once an attacker gains mailbox, portal, or admin access, they may inherit enough operational material to reach cloud control planes, backup systems, source code, or privileged automation.
That is why service desks should be treated as part of the NHI attack surface, not just a workflow system. The relevant question is not only who can read the ticket, but whether the platform holds long-lived secrets that outlast the request itself. NHIMG research shows how widespread this is: the Ultimate Guide to NHIs — Key Challenges and Risks highlights misconfigured vaults, poor visibility, and weak rotation discipline, all of which make support tooling an attractive place for secrets to accumulate. The Anthropic — first AI-orchestrated cyber espionage campaign report also reinforces that tool access and operational context can be chained in ways defenders often underestimate.
- Tickets may contain plaintext secrets that are searchable by admins, integrations, or attackers after compromise.
- Approvals can be legitimate, but the associated credential may remain valid long after the task ends.
- Automations often reuse the same account or token across many systems, increasing blast radius.
- Support staff may copy secrets into scripts or notes to reduce friction, creating shadow persistence.
Controls tend to break down when ITSM is integrated directly with production automation and the platform itself becomes the handoff point for credentials across multiple teams and vendors.
Where the Control Model Usually Fails
Tighter workflow control often increases friction for support teams, requiring organisations to balance fast incident handling against secret hygiene. There is no universal standard for exactly how every ITSM platform should handle NHI data yet, but current guidance strongly favours minimising secret exposure and shortening credential lifetime wherever possible.
The common failure is assuming RBAC alone solves the problem. Role-based access can tell you who may open a ticket, but it does not prevent a reusable token from being stored inside that ticket. Good practice is to issue Guide to the Secret Sprawl Challenge-style controls around secret discovery, redaction, and off-platform storage, then pair that with privileged workflows that keep secrets outside the ITSM system entirely. The Top 10 NHI Issues also underscores why rotation, visibility, and offboarding matter here: support repositories routinely retain access material long after the original need has passed.
In practice, the safer pattern is to replace shared or pasted credentials with short-lived, purpose-bound access issued from a proper secrets manager or PAM workflow, while keeping the ticket as evidence of approval rather than as the place where the credential lives. That matters especially in environments with heavy outsourcing, legacy ITSM customisations, or noisy automation, because those conditions make secret sprawl harder to detect and harder to unwind.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses poor secret rotation and exposure in support workflows. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central when ticketing systems store reusable credentials. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust limits lateral movement when workflow platforms are compromised. |
Limit ITSM access to need-to-know and remove direct access to secrets from tickets and attachments.
