Wiz and Unosecur integration reframes runtime identity security

At a glance

What this is: This announcement describes Unosecur joining Wiz Integrations Network to connect cloud visibility with runtime identity security across human and non-human identities.

Why it matters: It matters because IAM, NHI, and PAM teams increasingly need shared context to decide which identities to prioritise, where to reduce blast radius, and how to prove containment.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Unosecur's announcement on joining Wiz Integrations Network

Context

Runtime identity security matters because cloud teams often see inventory, misconfiguration, and exposure before they understand which identities are actually dangerous. In practice, the governance problem is not just finding risk, but deciding which human and non-human identities deserve immediate restriction at the moment of detection.

Unosecur’s partnership with Wiz is framed around that operational gap: shared findings, prioritisation, and remediation context for hybrid estates. The important question for practitioners is whether the integration reduces decision latency enough to change containment outcomes, especially where identity abuse moves faster than normal review cycles.

Key questions

Q: How should security teams prioritise identity findings in hybrid cloud environments?

A: They should prioritise by blast radius, reachable systems, and privilege scope rather than by raw alert volume. The goal is to identify which human or non-human identities can cause the most damage if abused, then restrict those paths first. That approach is more effective when cloud posture and identity context are evaluated together.

Q: Why do runtime identity controls matter more than periodic access reviews?

A: Because attackers operate at runtime, not on review cycles. Periodic reviews can confirm that access was once acceptable, but they do not stop a compromised session or abused service account in the moment. Runtime controls matter when the decision to restrict access must happen before the attacker pivots.

Q: What breaks when identity and cloud risk signals are not correlated?

A: Teams get more findings but less usable action. Without correlation, security staff see inventory, misconfiguration, and identity exposure as separate problems, which delays containment and makes it harder to decide which identity to restrict first. Correlation turns scattered telemetry into a response path.

Q: Who is accountable when JIT access fails to reduce exposure fast enough?

A: Accountability sits with the team that owns the identity governance workflow, not only with the cloud security tooling owner. If JIT access is slow, over-broad, or not tied to identity lineage, then the programme has not translated policy into enforceable runtime control. Governance must be measurable end to end.

Technical breakdown

Runtime identity prioritisation across cloud and SaaS estates

Runtime identity security differs from static entitlement review because the risk signal arrives from live cloud posture, not from a periodic access review. When a platform combines infrastructure findings with identity context, it can rank service accounts, users, and machine identities by exposure, privilege, and likely blast radius. That only works if discovery, enrichment, and enforcement share the same operational layer. Otherwise the team sees more data but not better control. The core technical issue is correlation at decision speed, not reporting volume.

Practical implication: wire cloud findings to identity controls that can act before an attack chain advances.

Blast radius reduction with just-in-time least privilege

Just-in-time least privilege aims to collapse standing access into short-lived access only when a task needs it. In hybrid estates, the control is most useful when privileges are both scoped and revocable across cloud, SaaS, and on-prem identities. That makes blast radius a design variable rather than an after-the-fact metric. If JIT is applied without strong identity context, teams may still grant the wrong identity the right privilege at the wrong time. The mechanism matters because the control is only as good as the identity data feeding it.

Practical implication: tie JIT workflows to identity context so privilege reduction is targeted, not blanket.

Identity timeline evidence and investigation speed

An identity timeline is useful when it reconstructs who or what touched which resource, in what order, and under which credential or session. For incident response, that shifts the question from whether an alert fired to whether the attack path can be proved and contained. In environments where compromised sessions, malicious plugins, or abused non-human identities are possible, timeline fidelity determines whether the team can separate signal from noise. Good investigation data is therefore a control surface, not just a forensics output.

Practical implication: preserve identity timeline data long enough to support containment, root cause analysis, and audit evidence.

Threat narrative

Attacker objective: The objective is to turn identity compromise into fast, multi-environment access with enough context to evade slow containment and widen the blast radius.

1. Entry occurs when a compromised session, malicious browser plugin, infostealer, or abused non-human identity is used to introduce attacker access into the environment.
2. Escalation occurs when that access is enriched by cloud context, privileges, or supply-chain exposure, allowing the attacker to move from initial foothold to broader identity impact.
3. Impact occurs when the attacker compresses dwell time, expands the blast radius, and reaches sensitive cloud, SaaS, or on-prem assets before defenders can contain the identity path.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime identity context is becoming the deciding layer in cloud security operations. Visibility alone does not tell teams which identities to restrain first, and that is the real gap this announcement exposes. When human and non-human identities are evaluated with infrastructure risk and timeline context together, the programme shifts from observation to prioritisation. Practitioners should treat identity context as the control plane for containment, not as a reporting add-on.

Blast radius is the more relevant metric than raw alert volume. The article’s emphasis on reducing identity attack surface, then using runtime workflows to contain exposure, reflects the direction identity security is moving. That matters because modern attacks do not fail when they are detected. They fail when access is narrowed before the attacker can pivot. Teams that still optimise for finding every issue rather than shrinking what each identity can reach are solving the wrong problem.

Human and non-human identity operations are converging in the same response workflow. The post is explicit that both identity types matter, which is the right operational framing. Identity programmes that separate user risk from machine risk will miss how attackers chain them together in hybrid estates. The practitioner conclusion is straightforward: governance, detection, and response now need a single runtime view across both identity classes.

Identity timeline evidence is becoming a governance requirement, not just an incident response artefact. If teams cannot reconstruct which identity acted, what it touched, and when privilege changed, they cannot defend their containment decisions or prove control effectiveness. That makes evidence quality part of identity governance maturity. Practitioners should expect auditors and incident leads to ask for that lineage, not just for remediation tickets.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, according to the same report.
• That combination makes the 52 NHI Breaches Analysis useful for teams mapping how weak visibility turns into real compromise paths.

What this signals

Identity programmes will need to treat runtime correlation as an operational requirement. If cloud findings, identity posture, and privilege scope stay in separate consoles, the response model remains too slow for modern attack chains. With only 5.7% of organisations having full visibility into service accounts, the gap is not cosmetic. It is structural, and the programme has to be redesigned around decision speed.

Human and machine identity governance is moving toward a single containment workflow. Teams that still separate user response from service account response will struggle to reduce blast radius when identities are chained together in the same attack path. The practical signal is whether your tooling can show who or what acted, what it can reach, and how quickly that access can be narrowed.

Identity timeline evidence should be treated as a control outcome. If your programme cannot prove session lineage and privilege change order, then incident response, audit, and governance are all drawing from incomplete evidence. That is why the 52 NHI breach patterns matter here: access abuse becomes easier when organisations cannot reconstruct the identity path quickly enough.

For practitioners

• Map runtime identity correlations to containment decisions Connect cloud posture findings, identity attributes, and privilege scope so the response team can immediately identify which identities should be restricted first. Use shared context to avoid treating all alerts as equal.
• Prioritise identities by blast radius, not by alert count Rank human and non-human identities by reachable systems, standing privilege, and exposure path. This keeps remediation focused on the access paths that matter most when an incident is active.
• Bind JIT controls to identity lineage Require the workflow to show which identity requested access, which resources it can reach, and how long the privilege remains valid. That reduces the chance of granting temporary access to the wrong subject.
• Preserve identity timeline records for investigation Retain action-order evidence, privilege changes, and session context long enough to support containment, root cause analysis, and audit review. Without that record, response teams lose the ability to prove how the incident unfolded.

Key takeaways

• The announcement is less about partnership optics than about runtime identity control becoming part of cloud response.
• The main security issue is not finding more findings, but shrinking the blast radius of the identities most likely to be abused.
• Teams that can correlate cloud posture, identity lineage, and JIT enforcement will respond faster than teams that keep those signals separate.

Key terms

• Runtime identity security: Runtime identity security is the practice of evaluating and enforcing identity risk while systems are actively running. It focuses on live privilege, session behaviour, and reachable assets, rather than treating identity governance as a static review exercise. In hybrid estates, it is the difference between observing exposure and containing it.
• Blast radius: Blast radius is the amount of damage an attacker can cause from a compromised identity or session. It is determined by reachable systems, privilege scope, and how quickly access can be narrowed. For machine and human identities alike, reducing blast radius is a core governance outcome, not just an incident response goal.
• Identity timeline: An identity timeline is an ordered record of identity actions, privilege changes, and resource access over time. It helps investigators reconstruct how an attack unfolded and helps governance teams prove whether controls worked. When accurate, it turns evidence into a security and audit asset.

What's in the full analysis

Unosecur's full news announcement covers the operational detail this post intentionally leaves for the source:

• How the Unified Identity Fabric is positioned across multi-cloud, identity providers, SaaS apps, and on-prem environments
• Which prioritized security findings are shared between Wiz and Unosecur, including inventory, vulnerabilities, issues, and configuration findings
• The vendor's description of no-code workflows, bulk remediation, and identity timeline evidence collection
• The stated workflow for reducing identity attack surface at runtime and narrowing blast radius after detection

👉 Unosecur's full announcement covers the runtime workflow, shared findings, and identity timeline detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.