Cyber threat landscape pressure is exposing security architecture gaps

At a glance

What this is: This panel discussion argues that rising attack pressure exposes gaps in security architecture, especially around third-party exposure and employee readiness.

Why it matters: It matters because IAM, NHI, and security teams need to design for adversaries that route around controls, not just for controls that work in ideal conditions.

Context

Cyber threat landscape pressure is not just a volume problem. It is a governance problem for identity, access, and detection programmes that assume a fixed control path will absorb every attack attempt.

In this panel from Venture Beat’s Intelligent Security Summit, Abnormal AI and Walmart speakers focus on third-party threats and employee preparedness. The core issue is that modern adversaries pivot across trust boundaries, which means security architecture has to be resilient across vendor access, human judgment, and downstream control handoffs.

Key questions

Q: What breaks when MCP security is treated as a single control layer?

A: Teams overestimate runtime coverage and miss the risks that sit above it. That usually leads to weak assumptions about intent validation, context leakage, and shadow endpoints, while the real control gaps remain unowned across identity, platform, and agent operations.

Q: Why do third-party relationships increase cybersecurity and liability risk for organisations?

A: Third parties expand the attack surface because their failures can become your operational and regulatory problem. If a partner suffers a breach, mishandles data, or weakens a critical process, the organisation remains responsible for safe and sound operations. The risk grows when oversight is based on trust, contracts, or reputation rather than structured assessment and control monitoring.

Q: How do security teams know if security awareness training is actually working?

A: Look for reductions in susceptibility over time, improved reporting behaviour, and fewer successful phish-to-access events. A useful programme measures outcomes by cohort, role, and channel, then compares those results with authentication and incident data. If training does not change behaviour or reduce downstream compromise, it is not functioning as a control.

Q: How should organisations balance architecture, third-party risk, and user training?

A: They should treat all three as complementary layers in the same defence model. Architecture limits blast radius, third-party governance reduces exposed trust paths, and user training lowers the odds that an attacker can exploit a human decision point to move deeper into the environment.

Background and context

Why adversaries route around fixed controls

Modern attacks succeed when defenders treat controls as a linear barrier rather than a set of overlapping, imperfect checks. A determined adversary can move from one weak trust point to another, especially when third-party access, SaaS integrations, and human decision points all sit inside the same environment. The security failure is not the absence of a tool, but the assumption that one tool can close every path. Practical implication: map where your controls depend on perfect detection instead of layered containment.

Practical implication: Map where your controls depend on perfect detection instead of layered containment.

Third-party exposure as an identity governance problem

Third-party risk is often discussed as a vendor-management issue, but it is also an identity problem because suppliers, contractors, and integrations extend your trusted access surface. When that access is not tightly scoped, continuously reviewed, and rapidly removed, the organization inherits another route for abuse. This is especially relevant where external parties touch sensitive data or workflows without the same lifecycle discipline applied to internal users. Practical implication: treat third-party access as governed identity, not just procurement oversight.

Practical implication: Treat third-party access as governed identity, not just procurement oversight.

Employee awareness remains a control layer, not a substitute

User training does not replace technical controls, but it can reduce the chance that an adversary lands a phish, social-engineers a handoff, or exploits ambiguity in a workflow. The useful lens is not whether training stops every incident, but whether it reduces the number of successful pivots after the first control fails. That makes awareness part of a layered defense model rather than a standalone programme. Practical implication: measure awareness by fewer successful follow-on actions, not by completion rates alone.

Practical implication: Measure awareness by fewer successful follow-on actions, not by completion rates alone.

NHI Mgmt Group analysis

Security architecture fails when it is treated as a single control point. The article’s central message is that adversaries are adaptive, so any programme designed around one decisive barrier will eventually be routed around. That is a structural governance problem, not a tooling problem. Practitioners should think in terms of control composition, containment, and recovery rather than faith in a single prevention layer.

Third-party access is one of the easiest places for trust to outlive its purpose. Supplier connections, outsourced workflows, and shared environments create identity paths that are often less visible than internal accounts but equally consequential. When those paths are not governed as part of identity architecture, they become durable attack surfaces. The implication is that third-party access must be owned as a lifecycle issue, not left as a periodic vendor review.

Security awareness is still part of the control stack because attackers target decision points, not just systems. Human judgment remains a live control surface when employees approve requests, open messages, or escalate issues under pressure. That makes awareness a resilience measure, not a cultural slogan. Organisations that ignore the human layer end up with architectures that look tight on paper but break at the first ambiguous interaction.

Identity programmes need a broader blast-radius model. The named concept here is identity blast radius: how far a compromise, bad approval, or external trust relationship can travel before containment stops it. That concept applies across human access, third-party access, and machine-linked workflows. Practitioners should use it to evaluate where their architecture prevents a local failure from becoming an enterprise event.

Continuous assurance matters more than control optimism. The panel’s point is not that detection or training should replace architecture, but that the programme must assume some controls will miss. That is why continuous review of third-party connections, employee decision points, and incident paths matters. Security teams should design for controlled failure, not perfect prevention.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Identity blast radius: security teams should assess how far a compromised vendor connection, phished user, or exposed workflow can move before containment starts. That shift matters because programme design now has to assume route-around behavior, not a single predictable attack path.

Continuous awareness is part of control resilience, but only when it is tied to specific decision points and measured by whether it reduces successful attacker pivots. Completion metrics alone do not tell you whether users are making safer choices under pressure.

For practitioners

• Map third-party trust paths Inventory every supplier, contractor, and integration that can reach sensitive systems or data, then document where access crosses organizational boundaries and where revocation would be delayed by process or ownership gaps.
• Review control handoffs for pivot points Identify places where one control depends on another team, another tool, or a human decision to complete containment, then close the gaps where an attacker could change direction without being stopped.
• Reinforce employee decision points Target training at the moments where users approve, share, or escalate access-related actions, because those are the points adversaries are most likely to exploit when technical controls are bypassed.
• Measure architecture by containment Test whether a compromised account, vendor link, or phished user can be stopped before it reaches broader systems, and use those results to judge whether the architecture is layered enough.

Key takeaways

• The article frames cyber risk as a resilience problem, not a simple tooling gap, because attackers can pivot around controls that were designed for orderly environments.
• Third-party exposure and human decision points remain high-value routes for abuse, so governance has to extend beyond internal systems and into supplier access and user behavior.
• Security teams should judge their programmes by containment and trust-path reduction, not by the assumption that any single preventive control will be enough.

Key terms

• Security Architecture Diagram: A security architecture diagram shows how systems, policies, and controls fit together across an environment. It is used to plan implementations, explain dependencies, and support compliance evidence by making the relationship between assets, protections, and operational responsibilities easier to understand.
• Third Party Risk: Third party risk is the chance that an outside organization, supplier, contractor, or service provider will create harm for your business. It includes security, privacy, operational, legal, and compliance exposure caused by access to data, systems, or processes. In identity terms, it often arises from shared credentials, integrations, and delegated trust.
• Action Layer: The action layer is the point where an identity moves from asking for access to doing something with that access. For AI agents, this layer matters because tool use can happen faster than human review, and the meaningful risk appears when actions are chained across systems.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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 building or maturing an IAM programme, it is worth exploring.