📋 For the boardroom The first three blogs in this series explained what a TLPT is, how to prepare for one, and where trajectories go wrong. This final blog answers the question that matters most: what do you actually learn? Based on our experience running TIBER and TLPT assessments, a well-executed TLPT consistently reveals three things that no other test can show you. This blog walks through each one.
Introduction
After three blogs on frameworks, preparation, and pitfalls, the question a CISO reasonably asks is: what do I actually get out of this?
Not in compliance terms. Not in framework deliverables. In genuine security insight.
The answer is different for every organization. But in our experience running TIBER and TLPT assessments, three categories of insight appear consistently:
- How your organization behaves under pressure, not just how your technology performs
- Whether your organization is structured to act on what your tools detect
- The edges of your threat model, including the boundaries you did not know you had drawn
These are the kind of insights that no penetration test or audit can produce.
What follows is based on our TIBER experience. The organization is fictional: Meridian Bank is a large pan-European bank providing a broad range of payment and financial services to corporate clients.
The threat intelligence identified two state-sponsored threat actors as most relevant to Meridian's profile: a Russian group with a history of politically motivated disruption targeting financial infrastructure, and a North Korean group with a decade-long track record of targeting payment systems for financial gain. A third scenario, physical infiltration, was added based on the geopolitical context and Meridian's specific infrastructure footprint.
Three scenarios. Three moments. Three things Meridian could not have learned any other way.
Insight 1: the supplier your Blue Team trusted, and the alert it misjudged
Meridian worked with a managed service provider that had legitimate, privileged access to parts of the internal network. The provider's IP addresses were known. The connections were authorized. The traffic patterns were established and familiar. To any monitoring tool, they were indistinguishable from a trusted partner.
The Red Team made use of that trust. Rather than attacking Meridian directly, they used the supplier's access pathway. Via a connection the Blue Team considered safe, they moved toward Meridian's critical payment systems.
The Blue Team received an alert. An anomaly in the supplier's traffic pattern, subtle but real, was flagged by the detection tooling. The alert was accurate. The threat was real.
The incident response playbook categorized traffic from trusted partners as low-priority by default. The analyst who reviewed the alert applied that categorization. The ticket was deprioritized. Two days later, the Red Team had achieved its objectives deep inside Meridian's network.
The lesson
The detection tooling worked. The analyst followed the process. But the process had a trust assumption embedded in it that no longer held. Supply chain attacks are the dominant vector for sophisticated state-sponsored actors precisely because they exploit the trust relationships that organizations have deliberately built and cannot easily remove.
The remediation was not technical. Meridian did not replace its managed service provider. It redesigned the trust architecture: behavioral baselines for third-party connections, separate alerting thresholds for anomalies in trusted partner traffic, and a response playbook that does not deprioritize alerts simply because the source is known.
The assessment also forced a conversation that had never happened: which suppliers have what level of access, to which systems, and who is responsible for monitoring that access? The answers were scattered across procurement, IT, and security. Nobody owned the complete picture.
What a TLPT reveals that nothing else does: your perimeter is defined by your suppliers, not just your own systems. And your detection is only as good as the assumptions built into your response process.
Insight 2: the employee who was never who they said they were
The second scenario simulated the North Korean group. Their approach is not primarily phishing emails. It is something more patient, more sophisticated, and considerably harder to detect.
A developer applied for a remote IT position at Meridian. The application was polished. The CV was convincing. The LinkedIn profile had connections, endorsements, and a history. During the video interview, the candidate was fluent, technically credible, and personable. The face on screen was generated in real time by AI software. So was the voice.
The candidate passed the interview and passed background checks using fabricated documentation. The candidate was hired, received a corporate laptop and legitimate network credentials, and began working remotely.
For six weeks, the work was performed adequately, using AI tools to produce code and respond to messages. During that time, Meridian's internal network was mapped, systems connected to payment operations were identified, and a persistent foothold was established using the legitimate network credentials. No phishing email. No external exploit. No anomalous connection from an unknown IP address. Just a new employee doing their job.
The lesson
The assessment surfaced three specific gaps. First, the onboarding process granted full network access from day one, without applying the principle of least privilege. Second, the security team had no visibility into behavioral anomalies on systems accessed by recently hired remote employees. Third, and most significantly, nobody had ever considered the recruitment process as an attack surface.
The Purple Teaming session that surfaced this finding produced one of the most uncomfortable conversations of the entire closure phase. Not because the Red Team had done something extraordinary, but because the attack vector was a legitimate hiring process. No security tool in Meridian's stack was designed to catch it.
What a TLPT reveals that nothing else does: your attack surface includes every process through which an external person gains legitimate access to your systems, including the processes that look nothing like security events.
Insight 3: the Red Team operator who walked in through the front door
Most organizations running a TLPT do not include a physical infiltration scenario. Meridian did, based on the threat intelligence and the geopolitical context at the time of the assessment.
The scenario assumed an attacker with a plausible reason to be in the building. The Red Team operators carried a get-out-of-jail-free card: a formal authorization letter confirming the legitimacy of their presence if stopped and questioned. It ensures that physical operators are not arrested for breaking in. It does not mean the assessment can continue, though. Once physical operators are identified, that element of the scenario is over.
The operators entered the building, moved through the office, and identified locations where network drop devices could be placed with minimal visibility and maximum connectivity. The devices were planted. Within hours, the Red Team had an additional foothold on the internal network, established entirely through physical presence in the building.
The building's electronic access controls and camera systems were functional throughout. Nothing failed. Nothing was bypassed. The Red Team simply walked in, because nothing in the environment was designed to stop them.
The lesson
The physical infiltration succeeded not because the building was insecure in a conventional sense, but because the threat model did not include physical access as a meaningful attack vector. Physical security and information security were governed by different teams, with different risk frameworks, and no shared threat model.
The assessment revealed something specific. The Blue Team had no visibility over devices connected to the network in public and semi-public areas: meeting rooms, reception zones, open workspaces. Smart TVs, printers, docking stations. None of them were monitored with the same rigor as workstations and servers. The drop devices blended into an environment that had never been designed with a physically present threat actor in mind.
The Gold Teaming session with the board made this tangible in a way that no report could. Several board members had offices in the building. The conversation between the security team and facilities management that followed had never happened before. After this scenario, it became a standing agenda item.
What a TLPT reveals that nothing else does: the boundaries of your threat model, including the boundaries you did not know you had drawn.
From findings to change: what the closure phase actually produces
This is where the real value of a TLPT is created. Not in the scenarios themselves, but in what happens after them.
The Purple Teaming sessions ran across multiple days, because for a good learning curve, multiple sessions are the norm. Each scenario was walked through in full: every Red Team action, every timestamp, every tool, cross-referenced against the Blue Team's own detection records.
For each scenario, the Purple Teaming sessions produced concrete and actionable output:
- Updated detection rules, tuned to the specific techniques, timing, and patterns the Red Team used, making future detection of similar attacks more reliable
- Revised response playbooks, replacing the trust assumptions and categorization rules that had allowed the Red Team to operate undetected for days
- Clearer ownership, defining who is responsible for monitoring third-party access, new employee behavior, and physical network access, filling gaps that had existed across procurement, IT, and security
The Gold Teaming session with the board translated the findings into investment decisions. Each finding was mapped to a business impact. Each remediation was mapped to a required investment. Three workstreams were approved with owners, budgets, and timelines: redesigning the trust architecture for third-party access, hardening the onboarding process and behavioral monitoring for new remote employees, and integrating physical security into the organization's threat model.
Together, the Purple and Gold Teaming sessions produced something more valuable than a list of findings: a priority-based testing calendar for the period ahead, committing Meridian to quarterly Purple Teaming scenarios to verify that the revised playbooks and detection rules hold up, and ensuring that the TLPT becomes the beginning of a continuous improvement cycle rather than a one-time exercise.
Three things a TLPT reveals that nothing else does
A standard penetration test finds vulnerabilities in systems. A TLPT does something different. It places a motivated and determined attacker in your live environment, under realistic conditions, with real consequences if your defenses fail. And it does so in a way that is structured, documented, and designed to produce insight rather than just findings.
For Meridian, the three consistent findings were not what they expected going in:
-
The supply chain scenario revealed that the organization's response process had a trust assumption embedded in it that no longer held. The team knew the alert was there. The playbook told them not to act on it. Knowing that suppliers are a risk vector is not the same as having built your detection and response around that reality.
-
The recruitment scenario revealed that the boundary between HR and security had never been drawn deliberately. It simply did not exist, because the need had never arisen. The attack succeeded not because of a vulnerability, but because of an absence: nobody had ever asked whether a new employee with legitimate access could be the attacker.
-
The physical scenario revealed a threat model with an implicit boundary. Not a deliberate choice, but an assumption so deeply embedded it had never been questioned. The building was secure. The network ports in the meeting rooms were not part of that conversation.
A TLPT does not just tell you where you are vulnerable. It tells you where you were not looking. And after nine months of preparation, execution, and structured learning, it gives you the clearest possible picture of the gap between the security program you think you have and the one you actually do.
Where to go from here
If you are still building toward your first TLPT, the most important step right now is not finding a Red Team provider. It is building the foundation that makes the test meaningful when you get there. Blog 2 in this series walks through exactly how to do that: the security testing strategy, the pre-TLPT preparation, the leg-up planning, and the organizational groundwork that separates a TLPT that produces strategic insight from one that produces a remediation backlog.
If you are already at the stage of selecting a TLPT provider, the conversation is different. You need a party that understands the full scope of what a TLPT tests: not just your technology, but your processes, your trust model, and the boundaries of your threat model. That is the conversation we are ready to have.
Either way, the organizations that get the most from their TLPT are the ones that start the right conversation early. We are ready when you are.
This is the final blog in our four-part series on Threat-Led Penetration Testing.
Blog 1: Understanding what a TLPT is | Blog 2: Building your pre-TLPT security testing strategy | Blog 3: Where TLPT trajectories go wrong