Notifications
Clear all
Topic starter
11/07/2026 8:42 pm
TL;DR: Identity security often stops at login, but internal chats, emails, tickets, APIs, and workflows can still be impersonated without cryptographic identity validation, according to eMudhra. The real problem is communication integrity, because authentication alone does not prove that a request, message, or action truly came from the claimed identity.
NHIMG editorial — based on content published by eMudhra: Identity management in communication and the security blind spot after login
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should security teams protect internal approvals and requests from identity spoofing?
A: They should treat approvals as identity events, not just workflow steps.
Q: Why do login controls fail to stop internal communication abuse?
A: Because login controls only prove identity at the edge, while attackers often act inside trusted channels after authentication.
Q: What do organisations get wrong about identity lifecycle management?
A: They often manage joiner, mover and leaver processes well for employees but leave non-human identities outside the same discipline.
Practitioner guidance
- Map identity-bearing communication channels Inventory every channel that can trigger access, approval, payment, or privileged change, including email, chat, helpdesk, API, and collaboration workflows.
- Require cryptographic proof for high-impact requests Use signed approvals, certificate-backed identity assertions, or device-bound tokens for requests that can change access or authorise sensitive action.
- Bind machine actions to accountable identities Assign ownership, certificate lifecycle, and revocation responsibility to every service identity that can send commands or request data.
What's in the full article
eMudhra's full article covers the operational detail this post intentionally leaves for the source:
- How PKI-backed identity validation can be applied to messages, approvals, and API calls.
- Where communication-layer identity fits alongside existing IAM, SSO, and MFA controls.
- How machine identity lifecycle automation supports microservices and cloud services.
- Why tamper-proof auditability matters in regulated workflows and collaboration channels.
👉 Read eMudhra's analysis of identity management in communication →
Identity management in communication: why login checks are not enough?
Explore further
11/07/2026 9:11 pm
Communication-layer identity is a control boundary, not a messaging feature. The article is right that the failure point is not login, but the trust decisions that follow it. In NHIMG terms, this is where identity security stops being a point control and becomes a continuous assurance problem across human, NHI, and machine interactions. Practitioners should treat any channel that can trigger privilege, payment, or access as part of the identity plane.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: Which frameworks are most relevant for communication-layer identity controls?
A: NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 are the clearest starting points because they align identity, access control, logging, and protection functions. For Zero Trust programmes, the key question is whether the organisation can verify identity continuously at the point of action, not only at login.
👉 Read our full editorial: Identity management in communication is the new trust boundary
