aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=GetSecretValue \
--max-results 5 \
--region <YOUR-REGION> \
--query 'Events[0].CloudTrailEvent' \
--output text

{
    "eventVersion": "1.11",
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROA123456789EXAMPLE:i-0c1a23fc456b7ab89",
        "arn": "arn:aws:sts::111122223333:assumed-role/YOUR-EC2-INSTANCE-PROFILE/i-0c1a23fc456b7ab89",
        "accountId": "111122223333",
        "accessKeyId": "ASIAIOSFODNN7EXAMPLE",
        "sessionContext": {
            "sessionIssuer": {
                "type": "Role",
                "principalId": "AROA123456789EXAMPLE",
                "arn": "arn:aws:iam::111122223333:role/YOUR-EC2-INSTANCE-PROFILE",
                "accountId": "111122223333",
                "userName": "YOUR-EC2-INSTANCE-PROFILE"
            },
            "attributes": {
                "creationDate": "2026-03-27T17:08:37Z",
                "mfaAuthenticated": "false"
            },
            "ec2RoleDelivery": "2.0"
        },
        "inScopeOf": {
            "issuerType": "AWS::EC2::Instance",
            "credentialsIssuedTo": "arn:aws:ec2:eu-west-2:111122223333:instance/i-0c1a23fc456b7ab89"
        }
    },
    "eventTime": "2026-03-27T17:12:54Z",
    "eventSource": "secretsmanager.amazonaws.com",
    "eventName": "GetSecretValue",
    "awsRegion": "eu-west-2",
    "sourceIPAddress": "1.2.3.4",
    "userAgent": "aws-sdk-rust/1.3.14 os/linux lang/rust/1.94.1 aws-secrets-manager-agent/2.0.0",
    "requestParameters": {
        "secretId": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
    },
    "responseElements": null,
    "requestID": "027507ea-f377-43d9-bf2f-646d4dc19223",
    "eventID": "f9c3ed0f-81f5-450b-a561-2b9e54fa9e73",
    "readOnly": true,
    "resources": [
        {
            "accountId": "111122223333",
            "type": "AWS::SecretsManager::Secret",
            "ARN": "arn:aws:secretsmanager:eu-west-2:111122223333:secret:your-secret"
        }
    ],
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "111122223333",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.3",
        "cipherSuite": "TLS_AES_128_GCM_SHA256",
        "clientProvidedHostHeader": "secretsmanager.eu-west-2.amazonaws.com",
        "keyExchange": "X25519MLKEM768"
    }
}

If you have feedback about this post, submit comments in the Comments section below.

Key Takeaways

• The real challenge in cybersecurity isn’t intelligence or visibility, it’s speed. Attackers operate at machine speed, while most organizations are still constrained by manual, human-driven workflows.
• Traditional threat intelligence falls short because it stops at insight. To reduce risk effectively, intelligence must not only inform decisions but also actively drive response.
• Fragmentation across cyber, fraud, and third-party risk creates exploitable gaps. A unified, intelligence-driven approach is essential to understanding and addressing modern threats holistically.
• Autonomous defense is the path forward. By enabling continuous, real-time action across the attack surface, organizations can close the speed gap and move from reactive security to proactive risk reduction.

For most security teams today, volume and access to intelligence isn’t the problem. It’s the speed at which they can turn that intelligence into action.

Over the last decade, organizations have invested heavily in threat intelligence and cybersecurity. Global security spending has surged past $200 billion annually, growing double digits year over year, while security’s share of IT budgets has climbed from under 9% to more than 13%. Most CISOs report continued budget increases, and enterprises are making billion-dollar investments in intelligence capabilities.

And yet, breaches still happen. Fraud still slips through. Third-party risk still catches teams off guard. The issue isn’t visibility. It’s the growing gap between how fast threats move and how fast organizations can respond.

Attackers now operate at machine speed, leveraging automation and AI to identify vulnerabilities, launch campaigns, and exploit opportunities in real time. Most security teams, however, are still constrained by manual workflows, fragmented systems, and processes that require human intervention at every step. That mismatch is where risk can accumulate—and where even well-resourced teams fall behind.

The Hidden Cost of Human-Speed Security

For many organizations, this gap shows up in subtle but compounding ways. Analysts spend hours triaging alerts, trying to determine which signals actually matter. Security teams often discover incidents after damage has already occurred, not because the data wasn’t there, but because it couldn’t be acted on quickly enough. Across the organization, teams responsible for cyber operations, fraud, and third-party risk operate in silos, each with their own tools and workflows, rarely sharing a unified view of risk.

At the same time, expectations from leadership have shifted. Executives and boards no longer want activity metrics—they want clear evidence that security investments are reducing business risk. But when intelligence is not clearly connected to action from security teams, that proof becomes difficult to deliver.

Traditional threat intelligence was designed to inform decisions made by humans, at human speed. In today’s environment, that model introduces delay. And delay, in cybersecurity, is increasingly indistinguishable from exposure.

Intelligence That Acts, Not Just Informs

Closing the speed gap requires more than incremental improvements. It requires a shift in how organizations think about intelligence altogether. Moving forward, the future of cybersecurity must be more than just intelligence-led—it must be intelligence-acted.

In this model, intelligence doesn’t sit in dashboards waiting for analysts to interpret it. It continuously correlates signals, prioritizes what matters, and drives action across the security environment automatically. Instead of asking teams to move faster, it enables the entire system to operate at the speed of the threat.

This is the foundation of autonomous defense, and it’s the future of effective, machine-speed cybersecurity.

From Reactive to Autonomous: A New Operating Model

Autonomous defense fundamentally changes the role of the security team. Rather than serving as the bottleneck between detection and response, analysts become decision-makers operating on top of continuously running intelligence.

Recorded Future’s Autonomous Threat Operations brings this model to life by eliminating the manual steps that slow teams down. It ingests and correlates intelligence from multiple sources, applies context in real time, and triggers actions across existing security tools—all without requiring constant human input.

The impact of such a dramatic shift is immediate and measurable. Threat hunting becomes continuous instead of periodic. Alerts arrive enriched with context, reducing the time needed to investigate and respond. Detection and remediation workflows execute automatically, freeing analysts to focus on strategic threats rather than routine triage.

Just as importantly, this approach transforms how organizations measure success. Instead of tracking activity—alerts processed, queries written, incidents reviewed—teams can demonstrate real outcomes: faster response times, reduced exposure, and a clearer connection between intelligence and risk reduction; the latter of which is becoming increasingly necessary for organizational buy-in.

This is so much more than just adding another tool to the stack. Instead, it’s about making every existing control smarter, faster, and more effective. And it’s paying off. On average, security teams using Recorded Future save up to 100 hours per week through improved analyst productivity, allowing teams to redirect effort toward threat hunting and proactive defense instead of repetitive manual analysis.

The Bigger Challenge: Fragmented Visibility Across the Attack Surface

Speed alone, however, is only part of the equation. Many organizations are also limited by how they view risk. Threats today don’t respect organizational boundaries. A phishing campaign can lead to credential theft, which can then be used to access systems, exploit third-party relationships, or enable fraudulent transactions. These events are connected, but still far too many organizations manage them in isolation.

Cyber operations teams focus on internal threats. Fraud teams monitor transactions. Risk teams assess vendors. Each group has visibility into part of the problem, but no one has a complete picture. This fragmentation creates blind spots, and attackers are increasingly skilled at navigating between them.

A Unified Approach to Risk

To effectively reduce risk, organizations need more than faster response times. They need a connected understanding of their entire attack surface, along with the ability to act across it in a coordinated way.

Recorded Future addresses this through four core solution areas—Cyber Operations, Digital Risk Protection, Third-Party Risk, and Payment Fraud Intelligence—all built on a single, integrated intelligence foundation.

In cyber operations, this means moving beyond alert overload to real-time prioritization. Instead of forcing analysts to sift through volumes of data, intelligence surfaces the threats that are most relevant to the organization’s environment and enables immediate action. The combination of prioritization and automation allows teams to reduce noise while improving both detection speed and response quality.

In digital risk protection, the focus shifts beyond the traditional perimeter. Today’s attackers target brands, customers, and executives just as frequently as they target infrastructure. By monitoring the open, deep, and dark web, Recorded Future provides visibility into impersonation campaigns, credential exposure, and emerging threats long before they impact the organization. More importantly, it enables rapid response, whether that means taking down fraudulent domains or preventing account takeover attempts.

Third-party risk represents another growing challenge. As organizations expand their ecosystems, they inherit risk from vendors and partners, often without real-time visibility. Third-party involvement in breaches has reached a staggering 30%, up from just 15% a year ago. Static assessments and periodic reviews can’t keep pace with how quickly vendor risk evolves today. Continuous monitoring, grounded in real-world intelligence, allows organizations to detect issues earlier, respond faster, and maintain a more accurate understanding of their exposure.

In the realm of payment fraud intelligence, the shift is equally significant. There were some 269 million records posted across dark and clear web platforms in 2024, and a tripling of certain e-skimmer infections. It’s important to keep in mind that fraud doesn’t begin at the moment of transaction. Rather, it begins much earlier, in the environments where stolen data is exchanged and tested. Recorded Future provides comprehensive coverage across the complete payment fraud lifecycle. Sophisticated cleanup and normalization techniques result in better data quality and richer data sets, reducing manual research and enabling high confidence mitigation actions. By identifying these signals upstream and intervening, organizations can stop fraud before it’s executed, reducing both financial loss and customer impact.

One Intelligence Foundation. Total Visibility.

What makes this approach fundamentally different is that these capabilities are not delivered as isolated solutions. They are unified through the Recorded Future Intelligence Platform, which correlates data across millions of sources and billions of entities to provide a single, coherent view of risk.

This unified foundation enables organizations to connect signals that would otherwise remain siloed. Threat actors, infrastructure, vulnerabilities, and campaigns are all linked, allowing teams to understand not just what is happening, but what is likely to happen next.

That level of visibility is what makes autonomous defense possible. And not just within a single domain, but across the entire attack surface.

The urgency behind this shift cannot be overstated. Attackers are already operating at machine speed, using automation to scale their efforts and reduce the time between discovery and exploitation. At the same time, organizations that rely on manual processes are finding it increasingly difficult to keep up.

The consequences of this gap are significant. Longer dwell times allow attackers to entrench themselves more deeply. Delayed responses increase the cost and impact of incidents. And as breaches and fraud events become more visible, customer trust becomes harder to maintain.

This is no longer a question of optimization. It’s a question of whether existing operating models can keep pace with the reality of modern threats.

Rethinking What Threat Intelligence Should Do

As organizations evaluate their approach to cybersecurity, the role of threat intelligence needs to be reconsidered. It is no longer enough for intelligence to provide visibility. It must enable action. It must operate in real time. And it must extend across the full scope of organizational risk—not just one domain at a time.

Equally important, it must deliver outcomes that matter to the business. Faster detection, reduced exposure, and measurable risk reduction are no longer aspirational. They are essential for enterprise security in the modern, AI-powered threat landscape.

The goal for most organizations isn’t to replace their security stack. It’s to make it work better. By enabling intelligence to act autonomously, connecting visibility across domains, and aligning security operations with the speed of modern threats, organizations can close the gap that has long existed between insight and action. Recorded Future is built to make that possible.

If your team is still struggling with alert fatigue, delayed responses, or fragmented visibility, the issue may not be a lack of resources. It may be a limitation in how intelligence is being applied.

Now is the time to rethink that model.

Connect with Recorded Future to see how autonomous defense can help your organization move at the speed of today’s threats—and stay ahead of what comes next.

Contact us

The paradoxes of today’s digital world are well-known to anyone with a smartphone.

Over the last decade, connectivity has expanded, yet the world has become more fragmented. Our everyday lives are more digital, but we spend more time parsing text messages for scams or deliberating the authenticity of potential deepfakes. Technology is delivering great productivity gains to small businesses while making them a larger target for cybercriminals.

In this environment, exposure becomes the default: Access points are growing, control is hard and reacting to change stops working. AI intensifies these dynamics because it compresses time for everyone, including adversaries.

Today, trust has become the most critical tool to move all businesses forward. Without trust, even the best ideas stall. People hesitate, adoption slows and growth stagnates.

Trust used to be something businesses tried to repair after a breach. Now it must be the starting point, and something to nurture and continuously prove in a world that has fundamentally changed.

It would be impossible to eliminate the risk entirely. Some estimates project cybercrime could cost the world $15.6 trillion annually before 2030, surpassing all but two of the world’s largest economies. Instead, the goal must be to build the ability to see sooner, decide faster and limit impact when, not if, something breaks. Trust today is all about bringing together speed, intelligence and collaboration, and that’s exactly what we’re developing across our teams.

Getting this right isn’t just good business sense, but the only way to ensure new technologies are embraced and economies can keep growing.

The advantage is intelligence

Real advantage comes from understanding context and connecting signals across systems. That’s what turns data into better decisions. This kind of intelligence increases speed, reduces risk and enables proactive action. With the right intelligence, teams can hunt for threats continuously, test assumptions and act before harm occurs, not just triage alerts after the fact.

You can see this shift in how the payments industry is evolving, including the work we’re doing by bringing Recorded Future’s threat intelligence together with Mastercard’s security capabilities, payments infrastructure and partnership models. We’re helping organizations understand where risk concentrates, how it propagates, and how quick, collective action can reduce the cost of cybercrime.

Faster insights mean earlier action, which minimizes impact — and deepens trust.

Trust is built through collaboration

Security doesn’t scale through isolated heroics. It scales through ecosystems: shared signals, shared standards and partners who can move together as new threats arise, attack vectors shift and failures spread.

Resilience is strongest when public and private sectors plan, exercise and respond together, rather than in parallel. Different players have different sightlines in the digital ecosystem. Startups look at the edges of innovation. Enterprises understand the realities of operating in today’s environment. Governments see where systemic risk concentrates. When those visions combine, our shields strengthen and expand, pushing cybercriminals out of the frame.

During our time here in Miami for the eMerge Americas conference, we’ve had the opportunity to speak to enterprises, startups, investors and government leaders about the need to accelerate resilience in Latin America, where the digital economy is booming but security hasn’t always kept pace. The region has the world’s fastest-growing rate of disclosed cyber incidents — in 2025 alone, Recorded Future tracked 452 ransomware incidents — but only seven countries have developed cybersecurity plans protecting critical infrastructure, and only 20 have formal computer security incident response teams.

That gap is where trust breaks, and where more collaboration can become a growth necessity. We can’t build sustainable economic growth in Latin America without building digital trust and cyber resilience. That’s why we are deepening our footprint here, enhancing regional threat intelligence and resilience and paving the way for stronger public-private collaboration to address these complex risks.

Secure digital access unlocks economic opportunity — and insecurity shuts it down fast. For a first-time digital user, one fraud incident can be enough to opt out for good. For a small business, one account takeover can wipe out months of progress. That’s why trust is inextricably linked to financial health. People can’t build stability on top of systems they’re afraid to use. At Mastercard, we’ve committed to connecting and protecting 500 million people and small businesses by 2030, because secure participation is foundational, not optional.

The bar for digital innovation today is not what we can deliver, but what people will trust enough to use, depend upon and harness for their own financial health. Because in the end, trust is the superpower.

AI vulnerability research and discovery capabilities are improving, but they have not changed the fundamentals of vulnerability management. Instead, they are scaling up problems familiar to vulnerability managers: patch prioritization and remediation backlogs.

For defenders, the timeline for determining which vulnerabilities matter most and remediating them before exploitation begins is narrowing, even as the overall volume of vulnerabilities rises. Organizations that rely on manual prioritization, slow patch cycles, or legacy software will face growing operational and security risks.

Figure 1: Reality versus hype of automated vulnerability research

The Vulnerability to Exploit Ratio

Vulnerabilities are software flaws attackers can use to gain access, run malicious code, escalate privileges, or disrupt operations. However, not every bug becomes a real-world threat: many are hard to reach, difficult to weaponize, or simply not worth an attacker’s time.

The total number of disclosed vulnerabilities has increased sharply in recent years, rising from roughly 21,000 in 2021 to nearly 50,000 in 2025. Part of that increase likely reflects stronger disclosure practices and bug bounty activity, though software growth, a broader attack surface, and more systematic reporting also play a role. Nonetheless, in 2025, Recorded Future only identified 446 vulnerabilities that were actively exploited in the wild, a reminder that confirmed exploitations remain a small fraction of total disclosures.

Figure 2: Yearly comparison of disclosed CVEs against CVEs with public exploits and vulnerabilities assessed as actively exploited by the Cybersecurity and Infrastructure Agency’s Known Exploited Vulnerabilities (KEV) Catalog and Recorded Future, 2021-2025

This is because attackers do not exploit every bug they find. Instead, they focus on developing exploits for the small subset of vulnerabilities that offer the best combination of reach, reliability, and return on investment, such as flaws that can be exploited remotely or affect widely used software. In other words, a vulnerability still has to be validated, turned into a reliable exploit, matched to a target, and integrated into an attack path worth the effort.

When a flaw matches the criteria, however, exploitation can move quickly. VulnCheck found that nearly 29% of KEVs in 2025 were exploited on or before CVE publication, a slight increase from the previous year, indicating the continued prevalence of zero-days and n-days. Much as their legitimate counterparts use AI in software development, adversaries are already using AI to accelerate parts of the attack workflow, including vulnerability research, exploit-path analysis, and malware development, even if its precise effect on exploitation timelines is hard to quantify. Some trackers estimate the median time-to-exploit may now be measured in hours rather than days, demonstrating the shortening window of time to act on a high-impact vulnerability.

How AI Changes the Equation

Anthropic and OpenAI recently drew significant attention through their limited release of what they claimed were uniquely powerful cyber defense models. An independent evaluation of Anthropic’s Mythos found significant improvements in multi-step cyberattack simulations. However, AI-assisted vulnerability discovery and penetration testing predate these models, and most frontier models have already demonstrated the ability to identify vulnerabilities and assist with exploit development. At present, these tools are still most effective in the hands of capable operators rather than enabling frictionless, low-skill exploitation at scale. This matters, too, as even if these capabilities are used primarily by security researchers in the near term, the resulting increase in disclosures, proofs of concept, and validated findings still adds to the defensive burden.

This impacts vulnerability management in three important ways:

• More credible vulnerability reports to triage: New agentic systems can do more than flag suspicious code; they can reason through program behavior, validate findings, and help identify which weaknesses appear most exploitable.
• Less time to mitigate exploitable vulnerabilities: Large-language models (LLMs) are accelerating the speed and scale of weaponization, meaning the path from disclosure to exploit could go from hours to minutes.
• Reduced the cost of exploit development: Emerging models appear more capable of producing proof-of-concept exploit code, testing attack paths, and helping skilled operators iterate toward weaponizable exploits faster than before.

Figure 3: The vulnerability equation: How automated capabilities will likely impact reporting, exploit development, and impact

More Reports, More Noise

Using AI agents for software code will almost certainly increase the number of reported vulnerabilities and developed proofs-of-concept. Microsoft’s April 2026 Patch Tuesday, which followed Anthropic’s Project Glasswing announcement, was the company’s second-largest on record. However, according to Microsoft, it “does not reflect a significant increase in AI‑driven discoveries, though [they] did credit one vulnerability to an Anthropic researcher using Claude.” The more important question is not whether more flaws will be found — because they will be — but whether defenders can process, validate, and prioritize them fast enough to act.

Vulnerability submissions are already overwhelming researchers’ ability to assess their overall risk, creating a backlog of vulnerability enrichment and scoring. If AI sharply increases the volume of plausible findings, defenders will face even more uncertainty around which vulnerabilities represent the next high-impact systemic event and which are background noise.

Less Time to Act

For the vulnerabilities that are actually a problem, defenders have even less time to respond. Automated exploit development will likely shorten the path from discovery to proof of concept and, in some cases, to weaponization for the subset of vulnerabilities worth pursuing. Adding to the triage problem, some medium-severity or otherwise “non-critical” vulnerabilities will need to be re-evaluated as possible components of exploit chains, even if they would not normally rank as urgent on their own.

Drowning out the Alarms

Even as defenders deal with more noise, a larger volume of reported, plausible findings is likely to increase the absolute number of high-impact exploits they need to address quickly. As a result, defenders face an even greater challenge in identifying the small subset of issues that matter most before attackers do.

This does not mean every newly disclosed flaw will be weaponized, or that high-impact, “internet-breaking” events will become commonplace; however, even a modest increase in exploited vulnerabilities puts more pressure on prioritization, patching speed, and compensating controls, especially for organizations already struggling with manual triage, slow patch cycles, or legacy software.

How to Use Automation for Good

For most organizations, the immediate risk is not that every vulnerability will suddenly be exploited, but that defenders will have less time to determine which findings matter most. Vulnerability discovery and exposure management should therefore be treated as related but distinct problems: AI may increase the number of findings, but defenders still need context to determine which exposures are actually reachable, high-impact, and worth urgent remediation.

In this environment, using AI-enabled vulnerability discovery, prioritization, and defensive remediation will be essential to keeping pace with attackers. The five actions listed in the following section can help organizations stay ahead of the threat.

1. Automate Vulnerability Prioritization and Response

Shift from CVSS-only scoring to real-time exploitability and exposure-based risk scoring to handle the surge in AI-assisted vulnerability discovery. Deploy automated scanning, validation, and threat hunting to identify exploitation activity quickly, especially in widely used software and internet-facing systems. Recorded Future’s Insikt Group regularly reports on new vulnerabilities and exploit trends and develops Nuclei templates to detect actively exploited vulnerabilities.

2. Accelerate Patching and Upgrade Cycles

As the time to exploit shifts from days to hours, the time to mitigate vulnerabilities will similarly shorten. Patch management will need to move faster, particularly for internet-facing systems, widely used software components, and critical dependencies. Automated remediation and automated compensating controls will likely become necessary to keep pace with AI-accelerated discovery. The Vulnerability Intelligence module in the Recorded Future Intelligence Operations Platform can help with prioritization based on the likelihood of exploitation. Ensure all automated actions are logged and regularly audited by a human, and require a human-in-the-loop for any actions on high-impact systems.

3. Reduce Dependence on Legacy and Unsupported Software

AI may make it easier for threat actors to identify and validate exploitable weaknesses in older, under-maintained codebases. Unsupported systems and aging software are likely to become increasingly difficult to justify unless they are strongly isolated and tightly controlled.

4. Shift Vulnerability Detection Earlier in the Software Lifecycle

Organizations should integrate automated security testing and AI-assisted vulnerability discovery into development pipelines. Early detection can help defenders fix vulnerabilities before production, reducing remediation burden later.

5. Get Ready for the Next High-Impact Event

Develop emergency response and mitigation playbooks specifically for high-impact, broadly applicable flaws, including scenarios where a patch is not immediately available. Preparation should include not just patching, but also containment measures such as segmentation, access restrictions, traffic filtering, and other compensating controls.

Threat intelligence can elevate cybersecurity programs from reactive to autonomous, transforming workflows and delivering measurable improvements. In a recent webinar, we shared practical steps for integrating threat intelligence into existing security stacks, optimizing workflows, and accelerating organizational maturity in cybersecurity practices.

Read on for actionable insights, frameworks, and tools shared during the session.

Bridging the gap: threat intelligence integration

The key to effective threat intelligence is making your tools work together seamlessly. Recorded Future doesn’t aim to replace your existing cybersecurity tools, but rather to enrich and connect them.

When Recorded Future connects to the tools already in your stack, it automatically adds contextually relevant threat intelligence to whatever you're working on. This can mean less manual effort and faster, better-informed decisions.

Understanding your organization’s cyber maturity

A useful starting point is assessing where your organization currently stands across four stages of cybersecurity maturity: reactive, proactive, predictive, and autonomous:

1. Reactive organizations focus on responding to incidents as they occur.
2. Proactive organizations hunt for threats before they lead to incidents and align detection systems to adapt toward emerging risks.
3. Predictive programs extend threat intelligence beyond the security operations center (SOC) to other organizational stakeholders.
4. Autonomous programs leverage automation to identify and respond to threats in real time at machine speed.

Maturity doesn't have to be assessed at the program level alone. Individual use cases may be at different stages. Alert management, for instance, may already be highly automated, while other workflows remain more reactive.

A helpful way to identify where to focus is to ask a series of questions, including:

• What does my current alert workflow look like?
• What's my most time-consuming process?
• What's my top priority for the next 12 months?

Your answers will enable you to identify areas for improvement and then prioritize your workflows as needed.

Three key integration workflows—and one bonus workflow

Next, we suggest integration workflows that are designed to help you optimize your security operations with Recorded Future threat intelligence:

1. Indicator of compromise (IOC) enrichment

Detection tools often generate alerts with limited context, leaving you asking why something was flagged and how risky it actually is.By integrating Recorded Future, you’ll find that those alerts can be automatically enriched with information such as malware families, exploited vulnerabilities, and threat actor connections—enabling better, faster decisions without additional manual research.

2. Vulnerability prioritization

Most organizations depend on CVSS scores or vendor-provided data to assess vulnerabilities, but that approach doesn't always reflect real-world risk. A more effective strategy is asking: Is this vulnerability being actively exploited in targeted campaigns? Are threat actors targeting my industry with it?

Recorded Future enhances vulnerability management primarily through threat intelligence context, with risk scoring that tells you why something is risky—specifically whether a CVE is being actively exploited in the wild, and whether it's targeting organizations in your industry.

3. Autonomous Threat Operations

The most advanced workflow involves automating threat detection and prevention from end to end. Recorded Future can identify emerging threats, initiate retroactive threat hunts, and automatically update detection and blocking lists in tools like EDR platforms—all without manual intervention. This will enable your security team to shift from reactive firefighting to real-time, autonomous threat prevention. Learn more about Autonomous Threat Operations, available in Recorded Future’s Professional and Elite pricing packages.

4. Bonus workflow: Watch list automation

Your existing vulnerability scanners like Tenable, Qualys, Wiz, and Rapid7 are already identifying vulnerabilities in your environment. A Watch List automation connector can link those tools directly into Recorded Future's Watch Lists, so the Platform automatically reflects your real threat footprint at all times. Instead of tracking a static list of top vulnerabilities, you get contextual intelligence tied to what's actually in your environment, and you're automatically alerted when vulnerabilities change in risk status.This shifts vulnerability management from a reactive posture to a predictive one, and makes prioritization effectively autonomous.

The role of Recorded Future’s Integration Center

The Integration Center makes it straightforward to connect with popular security tools including Splunk, ServiceNow, CrowdStrike, and SentinelOne. Many of these integrations are pre-built and can be activated in just a few clicks, meaning there may already be value waiting to be unlocked within your existing SIEM, SOAR, EDR, TIP, vulnerability management tools, GRC platforms, and more.

Driving business value with integrated threat intelligence

Beyond operational efficiency, well-integrated threat intelligence workflows build organizational trust and give security leaders a stronger, data-backed narrative about how their teams are operating. Automating enrichment and response creates the space to focus on strategic priorities—and makes it easier to demonstrate the program's value to leadership.

The path toward autonomous threat operations requires sophisticated technology, seamless integrations, smart prioritization, and strategic planning. The best approach is simply to start: Activate a workflow, see the value it delivers, and build from there.

If you need help getting started or have questions about your organization’s specific needs, book a custom demo.

If you’re a millennial or Gen Z-er, then you probably haven’t used a paper check in a while. According to the Federal Reserve Bank of Atlanta, just 1 out of 5 of your peers used a check in the last 30 days, versus 2 out of 5 Gen Xers and 3 out of 5 boomers. Yet despite year-on-year decreases in overall usage, Nasdaq Verafin saw check fraud instances rise another 11% in 2025.

Then again, if you are a millennial or Gen Z-er, you will have seen an advertisement for a cheap product on social media. For 40% of you, that has meant falling for an online shopping scam.

On the face of it, these look like two ends of the fraud spectrum:

• On the one hand, we have what feels like the past: paper check usage rates even among those aged 65+ fell from 13% of transactions in 2013 to 6% in 2025 (Federal Reserve Bank of Atlanta).
• On the other hand, we have the future: online shopping scams target a younger demographic through AI-enabled brand impersonation and sprawling social media ad ecosystems.

The payment instruments, demographics, and the teams working at financial institutions to address these problems differ. So what’s the thread linking them together? Business impersonation. It manifests itself differently across schemes, but for anti-fraud systems built to detect check washing and counterfeiting on the one hand, and unauthorized third-party card fraud on the other, business impersonation has emerged as the fraudster’s response to exploit both.

Commercial checks and copycat businesses across state lines

In the past, stolen checks were often whitewashed to change the recipient and amount, and then walked into banks for cashout. The Postal Inspection Service received over 299,000 mail theft complaints in a single 12-month period—a 161% increase from the prior year. Recorded Future’s Fraud Intelligence Team analyzed and mapped stolen checks to US geographies, illustrating hot spots of physical crime and observing that it remains a national issue that extends beyond heavily urbanized areas.

Mapping stolen checks by zip code; courtesy of Recorded Future

Yet even among declining consumer check usage rates, businesses’ use of commercial checks remains stubbornly high in the US: the Association for Financial Professionals (AFP) found that 91% of organizations are still using checks, and 63% experienced check fraud in 2024. When businesses send checks to suppliers, the amounts can rise quickly, leading fraudsters to expand beyond simple check-washing schemes.

In perhaps the most eye-catching example, fraudsters intercepted a commercial check destined for bubble-gum giant Bazooka in 2022. A $1.24 million check. Over the next two weeks, they transferred and withdrew over half a million dollars. How’d they do it? You can’t just wash out the payee name on a million-dollar check, replace it with John Smith, and expect it to clear after depositing it into a personal checking account.

Instead, the threat actors just created a fake Bazooka. The real Bazooka is registered in Delaware under the name “The Bazooka Companies, LLC”, so culprits registered a fictitious company in New York under the name “The Bazooka Companies 1 Inc”. They then used the official business license to open a corporate bank account for the new fictitious business. From there, they used cashier checks, withdrawals, and transfers to personal accounts to cash out the funds.

Fast forward to today, and the scheme is still happening. Recent research from Recorded Future Payment Fraud Intelligence (PFI) surveyed stolen checks for sale on Telegram in Q4 2025 and found over 30 checks with a business as the payee, along with suspicious new entities registered in other states a few days later. The total face value of the checks amounted to $2M.

As with most fraud, this scheme’s emergence is based on:

• Exploiting ecosystem gaps between disparate parties: Businesses can have the same name as another when registered in different states. Pair that with most states’ limited mandate to investigate business registrations, and we’re left with the first gap:

“As long as the basic filing requirements are met, the office[s] may have little or no authority to question or reject a document submitted for filing or to verify information included in the filing” (National Association of Secretaries of State, September 2025)

When a fraudster approaches a bank to open a business bank account, the bank conducts its own due diligence. But the focus here is on money laundering threats and the legitimacy of documents and applicants. If the fraudsters are using a clean identity — synthetic or otherwise — then the bank won’t have a clear reason to reject the application just because a business called John’s Toilet Supply, LLC exists in another state.

• Delivering a reactionary counterpunch to effective fraud processes: Think of this as the cat-and-mouse game. Fraud defenders figure out how to stop one scheme, forcing fraudsters to innovate. In this case, Positive Pay has proven remarkably effective at preventing check washing and counterfeit checks (when parties agree to use it). Payee Positive Pay, in particular, allows the payer to make sure that when their checks are deposited, the check number, date, payee name, and amount match their files. But what happens if everything is correct, but a copycat payee deposits the check? Cases like Bazooka.

80% discount on shoes? How can you say no?

If we detour into e-commerce, we see a very similar dynamic play out, but at a staggeringly larger scale. The premise is simple: use AI to launch a fake online shop impersonating company A, B, or C, buy ad space on social media to drive traffic, pocket the proceeds, and launder the funds while customers wait for goods that never arrive.

The scheme works because 53% of consumers, and 76% of Gen Zers, now begin shopping journeys on social media, according to Salesforce’s 2025 report. The problem is that the journey is littered with traps: in November 2025, leaked internal documents from Meta claimed the “company shows its platforms’ users an estimated 15 billion ‘higher risk’ scam advertisements — those that show clear signs of being fraudulent — every day”. Industry reporting paints the same picture, with the Better Business Bureau finding online shopping scams as the most reported scam type and social media advertisements as the most common originator.

The basics of the scheme are nothing new. Capture payment card data by creating a fake online store and advertise too-good-to-be discounts. What’s changed is that these are no longer just phishing websites. They’re functional online shops that process payments via merchant accounts. Behind each of these merchant accounts is a registered business.

This is creating problems throughout the ecosystem:

• Cardholders see websites that exactly mimic major (and increasingly niche) brands, letting discounts outweigh better judgment.
• Financial institutions face the challenge of balancing their duty of care to process customer transactions with the risks of fraud and money laundering. But in these cases, the traditional indicators of cyber-enabled fraud aren’t present. The cardholder is authorizing the transaction, and there’s nothing suspicious within the behavioral or device indicators of the 3D Secure authentication stream. (Because, again, it’s the cardholder doing the transacting under manipulation.)
• The fingers begin to point back at the acquirers and payment facilitators responsible for merchant onboarding, but, from their perspective, the entity holds a proper commercial license to engage in business issued by the local authorities. (Though, as a divergence from the check fraud scheme, the fraudsters in online shopping scams rarely impersonate a real big-name brand at the business creation and merchant onboarding stage. Instead, the fraudsters hide evidence of impersonation from the merchant onboarders and leave the impersonation for the ads and fake online shops visible to victims.)

But just like with the check fraud example, a big part of why online shopping scams have exploded — outside of generative AI making brand abuse content easier than ever to create at scale — is ecosystem gaps and fraudsters reacting to the defense:

• Exploiting ecosystem gaps between disparate parties: By the time a victim is making a purchase on an online shopping scam website, each entity along the way has looked to the one before and trusted that due diligence had been performed. The cardholder wants to trust that the social media platform screened out malicious advertisers; the card issuer wants to trust the cardholder vetted the merchant; the card network wants to trust the merchant onboarder verified the business; and the merchant onboarder wants to trust local authorities properly licensed the business. A big, long line of incentivized trust.
• Delivering a reactionary counterpunch to effective fraud processes: The industry has made huge strides in combating unauthorized, third-party card-not-present (CNP) fraud in the last decade. A major part of the success has been built on 3D Secure, introducing a layer of authentication on top of existing authorization controls. Online shopping scams completely sidestep the defensive layer by making the merchant the fraud surface and rendering cardholder authentication controls irrelevant.

Thinking towards the way out

On the check fraud side, the best solution may already be available, but, as with most solutions, it comes with trade-offs and adoption issues. The basic idea of Positive Pay and its derivative, Payee Positive Pay, is that a business informs its bank of the checks it is sending, and the bank only disburses funds if the check matches what the business provided. Positive Pay was designed to combat counterfeit and forged checks, and it does that very well.

Of course, in the Bazooka example of same-name business impersonation, this wouldn’t help. Nothing about the check was modified. So here, banks offer Reverse Positive Pay, which basically means the business personally signs off on each sent check. It can solve the problem but shifts more operational and investigatory expenses onto the business (which might explain why adoption rates are south of 20%, according to Datos Insights and Alkamai). In the end, though, it makes you wonder why not heed the advice and move to alternative electronic payment methods?

On the online shopping scam side, solutions are more complex and scattered across the ecosystem.

• At the top of the funnel, there’s rising pressure on online advertising platforms to do a better job at limiting the presence of fraudulent advertisements. Based on more leaked internal Meta documents, regulatory pressure may not be producing the desired outcome.
• At the merchant onboarding level, both the major card networks are forcing acquirers and payment facilitators to do more to defend the gates into payment processing, while also devoting more resources to identifying scam merchants that do make it in.

For card issuers on the frontline, it’s a more delicate dance. Card issuers aren’t on the hook for authorized card payments to fraudsters under the Fair Credit Billing Act (FCBA) or Electronic Funds Transfer Act (EFTA), but 67% of cardholders expect them to cover scam losses. Though when cards transacting on scam websites end up on the dark web for resale, and unauthorized charges start rolling in, it is the issuer’s problem.

The best solution aligns with the industry’s movement toward CTI-fusion models to address the cyber component of cyber-enabled fraud. The convergence of online shopping and purchase scams is precisely the type of problem the new organizational model was meant to combat.

In applying the CTI-fraud fusion model to purchase scams, traditional fraud assets start at the end of the fraud attack chain to correlate reported cardholder manipulation and non-delivery alerts against merchant account patterns. The CTI assets start at the beginning, sourcing online shopping scams at runtime and attributing the abused merchant accounts. The two teams then meet in the middle, using modeled transaction patterns and threat-hunted active scam websites, ultimately leading to the deployment of merchant-based fraud risk rules.

So, in the meantime, where does all this leave us? The same thing you’ve heard plenty of times: stop using checks if you can and don’t trust too-good-to-be-true offers from online ads.

How Recorded Future Helps

The research in this blog came directly from Recorded Future's Fraud Intelligence teams. Two capabilities speak to the threats described.

• Payment Fraud Intelligence — tracks the complete fraud lifecycle: for check fraud, it uses OCR to extract payee, amount, and date from compromised checks being sold in forums, enabling deposit screening against known stolen checks; for card fraud, it monitors compromised merchants, stolen cards on criminal marketplaces, and the tester merchants fraudsters use to validate cards before striking.
• Digital Risk Protection — provides continuous monitoring across millions of sources for malicious sites, brand and executive impersonation, data leakage, and dark web mentions — with risk-based alerting that surfaces only actionable threats and takedown workflows built directly into the Platform.

In March 2026, a group calling itself TeamPCP compromised LiteLLM (a Python package with roughly 97 million monthly downloads used by thousands of organizations to connect to AI services) and Checkmarx (one of the most widely used application security testing platforms on the planet). How they got in isn’t publicly confirmed. But the result was write access to a trusted software repository.

From there, they injected a credential-harvesting payload into the software and poisoned two Checkmarx GitHub Actions workflows. The malware ran silently on installation, vacuuming up access keys, cloud credentials, secrets, and (the cruelest irony) every AI API key that LiteLLM was specifically designed to manage. The stolen data was encrypted, then pushed to a lookalike domain.

And here is the part that should keep you up at night: this was one campaign, by one group, in one week. The downstream consequences are still unfolding.

Identity Is the Perimeter (and the Attack Surface)

The throughline in the TeamPCP campaign is identity. Start to finish.

TeamPCP intelligence summary courtesy of Recorded Future.

No one has publicly confirmed exactly how TeamPCP gained access to the LiteLLM maintainer’s repository, but the most likely vector is stolen credentials. Recorded Future’s identity intelligence contains almost 1 million compromised GitHub developer credentials harvested by infostealers and sold across dark web marketplaces. A single publishing token or access key, lifted from a prior infection and left unrotated, would have been sufficient. TeamPCPs’ earlier compromise of Aqua Security’s Trivy infrastructure in late February (where incomplete credential rotation left residual access open for weeks) demonstrates exactly this pattern: one stolen token, one missed rotation, and the door stays open.

Whatever the precise mechanism, TeamPCP used valid credentials to push malicious code into trusted repositories. No firewall to bypass. No endpoint to exploit. Just a valid login and the implicit trust that comes with it.

Then the payload itself was designed to steal more identities. Each compromised environment yielded credentials that unlocked the next target. Trivy led to GitHub Actions. GitHub Actions led to four additional software distribution ecosystems. One incomplete incident response created a cascading chain of supply chain compromises across five ecosystems in five days.

This is the identity and access management problem stated as plainly as possible: if the perimeter is identity, then every stolen credential is a breach in the wall. And unlike a firewall rule, a stolen credential doesn’t trigger an alert. It just works.

We previously wrote about how deserialization vulnerabilities have plagued enterprise software for over a decade. The pattern is always the same: trusting input that should not be trusted. Supply chain attacks are the organizational equivalent. We trust the packages we install. We trust the pipelines we build. We trust the security tools we deploy. TeamPCP exploited every layer of that trust, starting with a single compromised identity.

The Impact Is Not Just Ransomware

TeamPCPs’ Telegram channel references a ransomware victim’s site. The group appears to operate as a ransomware affiliate and has publicly discussed extorting companies by threatening to release over 300 GB of stolen data. Reports indicate a possible collaboration with the Lapsus$ extortion group. Ransomware is the obvious play.

CipherForce intelligence summary courtesy of Recorded Future.

But ransomware is only the most visible impact. The more dangerous question is: what else can you do with over a million stolen cloud credentials, API keys, and service account tokens?

The answer, based on what Insikt Group is tracking across multiple unrelated campaigns, is far broader than encryption and extortion.

Redirect payroll. Late last year (2025) Insikt Group was monitoring activity around a campaign called “Swiper,” run by likely Russian-speaking actors who set up phishing infrastructure impersonating major financial institutions and payroll service providers. Stolen credentials were transmitted in real time, enabling the actors to alter direct deposit accounts and redirect payments before anyone noticed. The responsible actor was identified through a dispute on a criminal forum, and their cryptocurrency wallet has processed over 7,000 transactions. This was a credential theft operation that converted identity compromise directly into financial theft. Now imagine that same playbook amplified by a supply chain attack that harvests payroll platform credentials at scale.

Reroute shipments. Separately, Insikt Group has identified TAG-160, a threat group targeting the US logistics and transportation sector. TAG-160 impersonates logistics companies, sends fraudulent rate confirmations via phishing emails, and delivers remote access malware. But TAG-160 has also been caught running “double brokering scams,” where they pose as a legitimate carrier, obtain valid load details from a real broker, then re-advertise the load under the broker’s name to contract a different carrier. The legitimate carrier moves the freight. The threat actor collects the payment. The real carrier never gets paid. A second, unrelated threat cluster targets German logistics companies with a similar playbook.

These are not theoretical scenarios. They are active campaigns running in parallel with the TeamPCP supply chain compromises. And the common denominator across all of them is credential theft and identity abuse.

In the five risk impact categories we use as a framework for translating cyber threats into business risk, the TeamPCP compromise touches every single one: operational disruption (ransomware, system lockout), financial fraud (payroll redirection, double brokering fraud, extortion payments), competitive disadvantage (credentials, trade secrets, PII), brand impairment (customers learning their security tooling was the vector), and legal and compliance consequences (breach notification obligations, potential liability for downstream impacts).

The tendency is to categorize supply chain attacks as a “security tool problem” or a “developer problem.” It is neither. It is a business risk problem whose blast radius extends from IT operations to payroll to logistics to the boardroom.

Organizations should ask how they can use AI-driven analysis to continuously verify the integrity of every package and build artifact entering their production systems. This means comparing distributed packages against their source repositories to detect injected code. It means analyzing updates to flag anomalous changes in behavior. It means automated provenance verification that traces software from source to distribution, flagging breaks in the chain.

But the TeamPCP campaign exposed a truth the industry has been slow to internalize: the security tools themselves are targets. TeamPCP specifically chose a vulnerability scanner and an application security platform because those tools have the broadest access to credentials and infrastructure. Compromising the tool that checks your code is the ultimate fox-in-the-henhouse scenario.

The organizations that weather this era of supply chain risk will be those that treat code integrity verification as a continuous, automated, AI-augmented process rather than a periodic audit.

So What. Now What.

TeamPCP is not done. Their Telegram channel explicitly states the operation is still unfolding, and they claim to be working with new partners to monetize stolen data at scale.

For security leaders, the immediate actions are straightforward: if your organization uses LiteLLM, Trivy, or Checkmarx GitHub Actions, assume compromise and rotate every credential on affected systems. Audit your software pipelines for unauthorized changes. Pin software dependencies to verified, immutable versions.

But the longer-term lesson is more fundamental. Supply chain attacks convert the trust model of modern software development into an attack surface. The packages you install, the tools you run, the pipelines you build: these are not neutral infrastructure. They are vectors. And the credential stolen today from a compromised software package could show up tomorrow as a payroll redirect, a rerouted shipment, or a ransomware demand.

The keys to your kingdom are scattered across every package manager, every automation token, and every service account in your environment. Someone is collecting them. And your supply chain breach is already someone else’s payday.

How Recorded Future Helps

The TeamPCP campaign left signals at every stage. Three Recorded Future capabilities speak directly to this threat:

• Identity Intelligence — monitors infostealer logs, dark web markets, and credential dumps in real time, automatically detecting compromised employee credentials and triggering immediate response — including the nearly one million compromised GitHub developer credentials already in Recorded Future's dataset.
• Insikt Group — elite analysts with deep government, law enforcement, and intelligence agency experience who produced the TeamPCP, Swiper, TAG-160, and CipherForce research in this blog. Customers see threats as they develop, not after they've made headlines.
• Third-Party Risk — continuously monitors vendors for ransomware extortion activity, breach indicators, and credential leaks, replacing point-in-time questionnaires with real-time visibility across your supply chain.

The global threat landscape didn't simplify in 2025. It shattered. Recorded Future's Insikt Group® 2026 State of Security documented how geopolitical fragmentation, state-sponsored operations, and criminal ecosystem adaptation reshaped global risk. Threats that once stayed in distinct lanes converged, and they converged fast.

Consider what Insikt Group® tracked last year:

• State-sponsored cyber actors shifted from intelligence collection to persistent access, pre-positioning inside target infrastructure so they can disrupt operations the moment geopolitical tensions escalate.
• Weak governance and systemic corruption fueled industrialized cybercrime, enabling payment fraud and criminal operations to scale like legitimate businesses.
• Influence operators and hacktivist groups multiplied alongside rising interstate conflict, amplifying fear, uncertainty, and doubt through exaggerated exploit claims.
• Loosely organized criminal collectives used social engineering to compromise third-party SaaS platforms, rapidly adapting to law enforcement action and traditional defenses alike.

The risk surface has expanded well beyond networks and endpoints. Your brand, your third-party vendors, your payment networks: each has its own threat actors, its own attack methods, and its own intelligence requirements. Yet most intelligence programs only cover one of these domains. Or they monitor them in silos, with no shared context.

The right intelligence, from the right sources, at the right time, is a critical competitive advantage. But intelligence only matters if you can act on it across every critical risk domain before attackers reach their objective.

Re-Imagining How Intelligence Is Delivered And Operationalized

Historically, Recorded Future has been sold on a per-user and per-capability basis - a model that worked well in a simpler world where security teams were focused on solving the most urgent problem in front of them.

Today’s threat landscape is fast, more complex, and deeply interconnected. Customers are no longer looking for point solutions, they’re asking for a fundamentally different way to consume and operationalize intelligence.

Customers are asking us to provide:

• Complete capabilities to support use cases aligned with core risk domains.
• Democratized access to intelligence across teams, workflows and systems.
• A simplified and predictable way to purchase for ease of budgeting and adoption.

In response, we’ve re-imagined Recorded Future is delivered:

“Four Solutions. Three Packages. One Intelligence Foundation.”

A unified approach designed to scale with your organization, accelerate time to value, and embed intelligence into every decision that matters.

Four Solutions for Four Critical Risk Domains

Your threats span your infrastructure, your brand, your vendors, and your payment networks. Your intelligence should too. We’ve re-organized our platform into four purpose-built solutions tied to distinct domains of enterprise risk.

Cyber Operations gives your security team the intelligence, workflows, and autonomous actions to detect, investigate, and respond to threats targeting your infrastructure. Alert triage, real-world vulnerability prioritization, malware analysis, proactive hunting: this is where reactive firefighting becomes predictive, intelligence-led defense.

Digital Risk Protection helps detect and disrupt threats that never touch your network but directly damage your business: brand impersonation, domain abuse, credential leaks, and phishing infrastructure across the open, deep, and dark web. With access to active infostealer logs and automated IAM remediation, your team can act on exposures within hours, not weeks.

Third-Party Risk delivers continuous, intelligence-driven monitoring of your vendor ecosystem. Security ratings combined with real-time threat intelligence surface breaches, ransomware activity, and dark web exposure days or weeks before formal vendor notification, giving your security and GRC teams evidence they can act on and defend to stakeholders.

Payment Fraud Intelligence identifies stolen payment cards, compromised checks, scam merchants, and web-skimming activity earlier in the fraud lifecycle, so financial institutions can stop losses before they materialize.

Each solution delivers complete, end-to-end capability for its risk domain. And because all four run on the same Intelligence Graph®, a signal detected in one domain immediately enriches context across the others.

Three Packages That Scale With Your Program

Modern organizations operate across multiple risk domains. We are introducing three packages that reflect that reality, meeting customers where they are and scale as their programs mature.

• Core is the foundation for intelligence-led security. It enables organizations to tackle essential use cases on day one - threat detection and alert triage, vulnerability monitoring, credential exposure detection, domain abuse monitoring, and executive impersonation protection. The package combines capabilities across Cyber Operations and Digital Risk Protection solutions, providing immediate, high-impact coverage.
• Professional is built for organizations ready to mature their program and operationalize intelligence at scale. Building on Core, it introduces deeper insights and automation to extend team capacity - enabling autonomous threat hunting, multi-source correlation, and external asset discovery. The result is broader coverage, faster response, and more leverage for security teams without adding headcount.
• Elite delivers the most comprehensive intelligence coverage available. By unifying Cyber Operations, Digital Risk Protection, and Third-Party Risk, it provides a complete view of risk across infrastructure, brand, and supply chain. With a single pane of glass, Elite operationalizes intelligence across workflows and teams—from CTI to SOC to Risk—driving smarter and faster risk-enabled decision making and response.

Across all packages, customers get full access to the Intelligence Graph®, Recorded Future AI, all compatible integrations, APIs, and Collective Insights. No hidden costs or barriers to connect to your existing security stack.

Built for Everyone Who Needs Intelligence, Not Just Analysts

Intelligence only creates value when the right people can act on it. That's why our platform packages include unlimited users. Every analyst, every engineer, every stakeholder who needs intelligence gets it, with no seat limits and no trade-offs about who gets access.

For smaller teams building early-stage programs, we still offer flexible user-based licensing so you can start where it makes sense and expand as your program matures. Either way, pricing is predictable. You know what you're paying, and you can scale with confidence.

Every package also includes unlimited integrations from Recorded Future’s hundreds of supported applications at no additional cost. Your SIEMs, EDRs, SOAR platforms, and ticketing systems all get equipped with real-time intelligence, so every analyst and engineer working in those tools benefits from enriched context without switching screens. Add Autonomous Threat Operations, and those same integrations become the foundation for autonomous hunting, detection, and prevention across your entire stack. Connected tools become an intelligence-led defense system that acts continuously, with minimal human intervention.

One Intelligence Foundation Across Every Domain

What makes this approach powerful isn't just simpler packaging. All four solutions and all three packages run on the same intelligence foundation: the Intelligence Graph®, correlating over 1.2 million sources and 26 billion entities across cyber, digital, third-party, and fraud domains.

A credential leak detected in Digital Risk Protection immediately informs a Cyber Operations investigation. A vulnerability under active exploitation triggers prioritized patching in your workflow. A third-party vendor breach surfaces before the vendor discloses it. Intelligence flows across your entire risk surface, giving you the correlated, high-confidence context that point solutions can't deliver.

That's what it means to be intelligence-led. Not consuming more data. Connecting signals across domains so you can act earlier, with greater confidence, at machine speed.

The Path Forward

Adversaries in 2026 are faster, more coordinated, and more resourceful than they've ever been. They operate across every attack surface simultaneously, and they're accelerating.

Whether you're a team of three building your first intelligence program or a global enterprise running intelligence-led autonomous operations, there's a clear path. Start with the solution or package that matches your priorities today. Grow into deeper automation and broader coverage as your program matures. And at every step, you're backed by the most comprehensive and independent intelligence platform in the industry.

We built this for the threats you're facing right now, and the ones coming next.

In March 2026, Insikt Group® identified 31 high-impact vulnerabilities that should be prioritized for remediation, 29 of which had a Very Critical Recorded Future Risk Score.

These vulnerabilities affected products from the following vendors: Cisco, Microsoft, Google, ConnectWise, Langflow, Citrix, Aquasecurity, Nginx UI, Qualcomm, F5, Craft CMS, Laravel, Apple, Synacor, Wing FTP Server, n8n, Omnissa, SolarWinds, Ivanti, Hikvision, Rockwell, and Broadcom. This month’s most affected vendors were Microsoft and Apple, together accounting for approximately 32% of the 31 vulnerabilities.

One vulnerability (CVE-2017-7921 affecting Hikvision) is approximately nine years old, reinforcing how attackers continue to exploit long-known weaknesses in environments where patching has lagged. Legacy and unpatched systems remain attractive targets. Defenders should not discount older CVEs; instead, they should prioritize based on observed activity, maintain strong asset visibility, and apply compensating controls where remediation is not possible.

In March, Insikt Group® created Nuclei templates for a high-severity path traversal vulnerability in MindsDB (CVE-2026-27483) and a critical missing authentication vulnerability in Nginx UI (CVE-2026-27944). Additionally, Insikt Group® had already published a Nuclei template for CVE-2025-68613 (n8n) in December, prior to its exploitation this month. We also identified public proof-of-concept (PoC) exploits for 10 of the 31 vulnerabilities.

Quick Reference: March 2026 Vulnerability Table

All 31 vulnerabilities below were actively exploited in March 2026. The table below also provides examples of public PoCs identified by Insikt Group®. These PoCs were not tested for accuracy or efficacy. Vulnerability management teams should exercise caution and verify the validity of PoCs before testing.

Table 1: List of vulnerabilities that were actively exploited in March based on Recorded Future data.

Key Trends: March 2026

• Most commonly observed weaknesses: CWE-502 (Deserialization of Untrusted Data) and CWE-94 (Code Injection).
• Two vulnerabilities and one exploit kit (consisting of 23 exploits, 12 of which are currently associated with specific CVEs) were linked to malware campaigns.
  • Interlock Ransomware Group exploited a zero-day in Cisco Secure Firewall Management Center to compromise enterprise networks, deploy custom remote access trojans (RATs), and facilitate ransomware operations.
  • Separately, the DarkSword iOS full-chain exploit enabled Safari-based remote code execution (RCE), sandbox escape, and kernel-level access, leading to deployment of the GHOSTKNIFE, GHOSTSABER, and GHOSTBLADE payloads.
  • The Coruna exploit kit similarly compromised iOS devices to deliver the PlasmaLoader (PLASMAGRID) malware.
• 9 of the 31 vulnerabilities (CVE-2026-3910, CVE-2026-33017, CVE-2025-32432, CVE-2025-54068, CVE-2026-20963, CVE-2025-68613, CVE-2025-26399, CVE-2021-30952, and CVE-2023-41974) allowed attackers to conduct RCE.
  • These 9 vulnerabilities affected Google, Langflow, Craft CMS, Laravel, Microsoft, n8n, SolarWinds, and Apple.

Exploitation Analysis

This section analyzes two of the highest-impact, actively exploited vulnerabilities this month. Where applicable, it also highlights the availability of Nuclei templates created by Insikt Group®. The full list of reports and detection rules from March is available to customers in the Recorded Future Intelligence Operations Platform.

Interlock Ransomware Group Exploits Cisco FMC Zero-Day (CVE-2026-20131)

On March 18, 2026, Amazon Threat Intelligence published an analysis detailing an ongoing Interlock ransomware campaign exploiting CVE-2026-20131. CVE-2026-20131 is a critical vulnerability affecting Cisco’s Secure Firewall Management Center (FMC) software that allows unauthenticated threat actors to execute arbitrary Java code as root on vulnerable devices. Cisco Secure FMC is a centralized management platform that allows administrators to configure, monitor, and control Cisco firewall devices and network security policies across an enterprise environment. According to Amazon Threat Intelligence, Interlock Ransomware Group exploited CVE-2026-20131 as a zero-day vulnerability beginning January 26, 2026, indicating active exploitation prior to its public disclosure and enabling early compromise of enterprise networks.

The Interlock Ransomware Group exploits vulnerable Cisco FMC instances via crafted HTTP requests exploiting CVE-2026-20131 to execute arbitrary Java code as root. After gaining access, the threat actors deploy a malicious ELF binary from a staging server at 37[.]27[.]244[.]222 (Intelligence Card) to support follow-on operations.

They then use custom Java- and JavaScript-based RATs, a memory-resident web shell, and proxy infrastructure to maintain access, enable lateral movement, and evade detection. Post-compromise activity includes reconnaissance, data collection and staging, and the use of legitimate tools such as ConnectWise ScreenConnect, Volatility, and Certify for remote access, credential theft, and privilege escalation.

Insikt Group® obtained a screen locker sample (SHA256: 6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f) shared by Amazon Threat Intelligence from Recorded Future Malware Intelligence. Sandbox analysis detected the sample as benign. Based on sandbox and static code analysis, the sample performs the following actions on a victim’s machine:

• Changes the machine’s desktop wallpaper that displays a pornographic image
• Delays execution using the Sleep API function for evasion
• Detects debuggers using the GetTickCount API function to compare timing

Figure 1: Risk Rules History from Hash Intelligence Card® for 6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f in Recorded Future (Source: Recorded Future)

There's a category of employee credentials where standard monitoring often falls short: executives, finance leaders, IT administrators, and those with privileged access have a large target on their back.

VIP Credential Monitoring in Recorded Future is built to solve this problem. It continuously monitors for credential exposures tied to your most sensitive individuals across both work and personal accounts, and alerts your team fast enough to act before an account takeover occurs.

The Challenge with Protecting Your Most Targeted People

According to Verizon's 2025 Data Breach Investigations Report, credential abuse was the most prominent initial access vector observed across breaches. Attackers don't need to find a technical vulnerability to get inside your organization. Stolen credentials are widely available across criminal forums and dark web marketplaces, and buying access is often faster and cheaper than building an exploit.

What makes this particularly calculated is how threat actors decide which credentials to buy. Infostealer malware logs don't just capture usernames and passwords — they capture the authorization URLs where those credentials were entered. According to Recorded Future’s 2025 Identity Threat Landscape Report, 7 million credentials were indexed with identifiable authorization URLs, with 63.2% of those having been linked to authentication systems.

Figure 1: Top authorization URL categories, 2025 (Source: Recorded Future)

That means attackers can usually identify the access endpoints credentials unlock and they will prioritize accordingly. Executives and anyone with broad access to systems and data sit at the top of that list.

The 2025 cyber attack on University of Pennsylvania illustrates exactly how this plays out. A threat actor compromised a single employee's SSO credential and used it to move laterally across corporate systems, ultimately exposing data on approximately 1.2 million donors, alumni, and students. One credential, one login, and an organizational crisis.

The threat doesn't stop at corporate accounts. When attackers can't get hold of an executive's work credentials, they target personal accounts for these high-value targets. A personal email or social account can expose sensitive communications, private information, or material an attacker can use for extortion.

Corporate security controls don't extend to personal accounts. When those credentials are stolen, most security teams have no line of sight.

That gap between exposure and discovery is where the risk lives. Credentials stolen by infostealer malware are often purchased and weaponized within 48 hours of the compromise, potentially days or weeks before a security team has any indication something is wrong. For standard employee accounts, that window is serious. For your CEO or Head of Engineering, it's critical.

Monitoring Built for High-Value Targets

VIP Credential Monitoring provides continuous monitoring and alerting on compromised credentials for your high-value targets. Security teams can add personal or work email addresses for their executives and others with widespread access.

From that point forward, Recorded Future continuously monitors for those accounts across its full source coverage: infostealer malware logs from 30+ malware families, dark web forums, criminal marketplaces, paste sites, and breach dumps. When a VIP credential surfaces in that data, the team receives an alert with full contextual detail (malware family, authorization URL, compromised host information, etc.) so they can act with confidence.

Many executive monitoring solutions surface credential data that is days or weeks old by the time it reaches an analyst. By then, the window to get ahead of an attacker has often closed. For all stolen credentials indexed in 2025, Recorded future detected 36.4% within 24 hours of exfiltration, and 52.9% within one week.

The gap between when credentials are stolen and when a security team finds out is where breaches happen. Recorded Future closes that gap.

When a VIP credential appears in exposure data, teams can initiate a password reset, review active sessions, or reach out directly to the individual — all before the credential is exploited. For identities that carry this level of organizational risk, getting ahead of the exposure isn't just operationally valuable; it can be the difference between a resolved alert and a significant incident.

A Complete Picture of Identity Exposure

VIP Credential Monitoring is built on the same intelligence infrastructure that powers Recorded Future Identity Intelligence broadly: the same source coverage, the same detection engine, the same alert and triage workflow. It applies that capability to a category of identities that warrant closer attention, without requiring a separate tool, process, or integration. That's the logic behind Identity Intelligence as a whole: a unified view of credential exposure across every category of identity your organization needs to protect, covering employees, customers, and your highest-risk individuals.

For teams already using Identity Intelligence to monitor employee and customer credentials, VIP Monitoring is a targeted extension of coverage that fits into what they've already built. Any VIP credentials identified will benefit from the same core features of Identity Intelligence.

This includes Incident Reports, which surfaces any other credentials that may have been compromised from the same machine, and Customizable Alerting, which streamlines prioritization of these detections and can trigger response workflows through existing integrations with Okta, Microsoft Entra ID, XSOAR, Splunk, and others.

Attackers don't limit their targets to one type of account, and your monitoring shouldn't either. To see where you stand today, request a free Identity Exposure Assessment Report and get a concrete, evidence-based picture of your organization's credential exposure over the past year. Contact us to learn more about how Recorded Future can help your organization protect its identities and to see a demo of the platform in action.

For years, the cybersecurity industry has treated third-party risk management as a compliance exercise. Assess your vendors. Assign a score. File the report. Move on. That model was built for a different era. One where supply chains were smaller, threat actors were less sophisticated, and a quarterly questionnaire could reasonably approximate a vendor's security posture. That era is over.

Today, the average enterprise works with hundreds of third parties. Threat actors actively target the weakest links across those supply chains, not because the vendors themselves are the prize, but because they're the path of least resistance into larger, more valuable targets.

Ransomware groups list vendors on extortion sites before those vendors even know they've been compromised. Stolen employee credentials surface on dark web forums undetected. Critical vulnerabilities are weaponized in hours, not months. In this environment, a security rating is necessary. But it is nowhere near sufficient.

Recognized in the 2026 Forrester Wave™

Recorded Future was recently included in The Forrester Wave™: Cybersecurity Risk Ratings Platforms, Q2 2026. (The report is available online to Forrester customers or for purchase here).

We see this recognition as a reflection of the market's evolution — and as an acknowledgement of the direction we've been building toward.

We believe the cybersecurity risk ratings market is at an inflection point. Analysts and practitioners alike recognize that the category is moving beyond standalone ratings toward integrated intelligence and actionable insights. We see our inclusion in this evaluation as confirmation that the convergence of hygiene data and threat intelligence isn't a niche play — it's where the market is heading. In light of where the ratings market is today, let’s dive into where Recorded Future is going and how Recorded Future envisions the future of securing the third-party ecosystem.

The Gap Between Hygiene and Intelligence

Cyber risk ratings have earned their place in the security stack. They provide a standardized, scalable way to evaluate a vendor's external security posture — patching cadence, encryption practices, DNS configuration, exposed services. That hygiene baseline matters. It's a correlative signal for breach potential, and it gives risk teams a common language for comparing vendors and benchmarking against industry peers.

But hygiene ratings only answer part of the problem: How well is this vendor maintaining their defenses?

They don't tell you whether anyone is actively trying to breach those defenses. They don't surface the dark web chatter on a specific vendor. They don't alert you when a vendor's credentials are leaked or has an active malware infection. This is the gap that has left third-party risk programs perpetually reactive. Teams learn about vendor compromises from news headlines or from the vendors themselves — often days or weeks after the initial breach. By then, the window for proactive response may have closed.

From our own customer conversations, we hear that security and risk teams have shifted from wanting ratings and accuracy alone to demanding intelligence that reveals real cybersecurity risk, with prioritized findings and actionable remediation guidance. Ratings are increasingly commoditized. The differentiation now lies in what you do with the data, and what additional signals you bring to the table.

Third-Party Risk Management Is an Intelligence Operation

If you accept that ratings alone aren't enough, the logical next step is clear: third-party risk management must be treated as an intelligence operation.

That means combining the hygiene baseline — the outside-in view of a vendor's security posture — with real-time threat intelligence that tells you who is being targeted, how, and what you should do about it. It means shifting from periodic assessments to continuous monitoring. It means equipping risk teams with the context to distinguish between a low-priority configuration issue and a vendor whose infrastructure is actively under attack. This is the problem Recorded Future Third-Party Risk was built to solve.

We've brought together two distinct capabilities that, until now, existed in separate worlds.

1. RiskRecon — built over a decade as one of the industry's leading cyber risk ratings platforms, trusted by 21,500+ users across 30+ industries, provides the hygiene foundation: transparent, evidence-backed security ratings evaluated across 40+ criteria in 9 security domains, with 99% audited data accuracy.
2. Recorded Future's threat intelligence capabilities, powered by collection and analysis across more than 1 million sources, adds the threat dimension: real-time alerting on ransomware extortion activity, dark web exposures, credential leaks, and active vulnerability exploitation — often before the affected vendor is even aware.

Together, these capabilities create something the market hasn't had before: a single solution that covers the full lifecycle of third-party risk, from initial assessment and onboarding through continuous monitoring and incident response.

What This Looks Like in Practice

The value of combining hygiene ratings with threat intelligence isn't theoretical. Our customers are already seeing it play out.

• When a vendor appears on a ransomware extortion site, Third-Party Risk customers can receive alerts in hours — not the days or weeks it takes for vendor self-disclosure.
• When credentials associated with a monitored vendor surface on dark web markets, risk teams can initiate outreach and remediation before those credentials are weaponized.
• When a critical vulnerability is disclosed, intelligence context helps analysts determine which vendors are actually exposed and at risk of exploitation, rather than treating every vendor with the affected software as equally urgent.

Customers consistently report a roughly 33% increase in visibility into third-party risks after adopting the platform (UserEvidence). Teams save an average of 7 hours per week that was previously spent on manual research and monitoring (UserEvidence). And customers routinely detect vendor incidents before the vendor itself has disclosed — turning what used to be a reactive scramble into a controlled, proactive response.

These aren't incremental improvements. They represent a fundamental shift from reactive compliance to proactive risk management.

Where We're Going

We're not done. Bringing RiskRecon and Recorded Future together was the first step in a broader vision for what third-party risk management should become.

Our roadmap is focused on deepening the integration between these two platforms into a unified experience. One where hygiene ratings, threat intelligence, and risk workflows operate seamlessly together. We're investing in AI-driven capabilities that will help risk analysts cut through noise faster, automate routine assessment workflows, and surface the insights that matter most. And we're building toward predictive intelligence that doesn't just tell you what's happening now, but helps you anticipate where risk is headed.

The goal is straightforward: make third-party risk management as data-driven, automated, and intelligence-led as the best security operations programs already are.

Join the Shift to Intelligence-Driven Third-Party Risk

Third-party risk programs that rely exclusively on hygiene ratings will continue to be caught off guard. The vendors who score well on a Tuesday can be breached by Wednesday. The questionnaire response you received last quarter may not reflect today's reality.

The organizations that are getting ahead of this are the ones treating third-party risk as what it actually is: an intelligence operation that requires continuous monitoring, real-time alerting, and the context to act decisively when something changes.

That's the future we're building. And we believe we're the only ones building it with the depth of intelligence and the strength of ratings data required to get it right.

November 20, 2025: Original publication date of this post. This post has been updated to reference the most recent version of the LZA Compliance Workbook published to AWS Artifact in March 2026.

If you have feedback about this post, submit comments in the Comments section below.

Read the Full Video Transcript:

I’m Kyle Kohler. I’m a product manager over the integration strategy at Recorded Future.

Recorded Future is the world’s largest threat intelligence provider. We are covering all sorts of domains of intelligence. It’s geopolitical intelligence, cyber intelligence, payment fraud intelligence. And essentially intelligence is this data that an organization uses to take action and make a better decision. So the more that you understand a subject or topic, a current event, the better that you can define what actions you take to either defend your organization or proactively increase your competitive edge.

As a product manager, it’s funny. I see it as this arson firefighter educator role. And I think that definitely needs to be unpacked a bit. As an arson, you’re starting fires. So, very strategically, which fire do I put under which team, under which initiative, which fire do I stoke and one do I burn hotter? And as a firefighter, you’ve got maybe fires coming in being reported to you from a customer, from an organization, from another product team who needs this other product team to make something happen. And so, you’re very strategically figuring out what to stamp out, what to stoke. And as an educator, you’re also teaching others how to start fires and put out fires. So, you’re constantly going from one thing to the next and keeping all of these moving pieces going. There’s no one project that you just shepherd along and that’s the only thing you work on. You’re constantly context switching and a good product manager has that multi-domain knowledge to think laterally, but also track how this thing affects that thing and how it might affect the other thing in the future.

At Recorded Future, we’re a global organization and I’m based on the west coast of California. So I wake up in the morning and the first thing I’ve got are 10 to 12 Slack messages from across the globe that come in from different geographies. Other people are ending their day and they’ve got some questions that maybe I can answer or they’re looking for how to direct on who might have the right answer. So the first thing generally starts with voraciously checking Slack and I’m answering notifications as I mentioned questions and the next thing is okay well from the answers to those questions are there new initiatives that need to get spun up or are there existing initiatives that need to get nudged along or are there certain fires that need to get stamped out and that’s the whole day is you’re really tracking where things are in their current state what needs to get responded to and what needs to get pushed along.

Recorded Future really was attractive to me because it was a pretty new field within cyber security and within technology but also as a company was not just related to IT and cyber had this geopolitical and payment fraud type of angle looking at the world. So it was really taking a big data problem how do you track everything that happens everywhere but then how do you break that down into these bite-sized pieces that ultimately help an organization’s current mission. So I really was attracted by the fact that we are helping organizations secure the world. We’re able to do that by securing the world with intelligence, but it’s so multi-domain that you’re just never going to get bored. There’s always something new. There’s always something to track. There’s always some new threat. There’s always some new initiative, some new innovation. And Recorded Future has really been at that cutting edge of innovation. Always coming up with what’s next in the market, what’s next in the threat landscape and how will we as a company address supercharging the existing missions of our organizations that we help today.

Original content: https://venturefizz.com/insights/what-i-do-at-recorded-future-senior-product-manager/

Payment fraud no longer operates as a collection of discrete schemes run by individual threat actors.

It is increasingly sustained by an industrial support ecosystem: purpose-built infrastructure, packaged toolkits, and professionalized services that allow threat actors to maximize fraud output while minimizing the skill and effort required to execute attacks.

According to Recorded Future's Annual Payment Fraud Intelligence Report: 2025, this industrialization was driven by technical advances and increasingly professionalized support services.

The Magecart e-skimmer supply chain is the clearest example. Full-stack e-skimmer kits and Malware-as-a-Service (MaaS) offerings have made large-scale compromise of ecommerce websites accessible to less technically capable threat actors.

The "Sniffer by Fleras" kit, responsible for 26% of all e-skimmer infections observed in 2025, includes a web-based portal for generating malicious scripts and a management server for stolen data. The result was more than 10,500 unique Magecart infections active at some point during the year, likely compromising more than 23 million transactions.

Additionally, the "AcceptCar" e-skimmer, discovered in H2 2025, illustrates how far the service model has matured. Operators handle installation and operation on compromised e-commerce sites; in return, threat actors pay 50% of proceeds from card data sales or 70% of raw data intake. Using services like AcceptCar, fraud threat actors can participate in large-scale compromise operations without owning or managing any underlying infrastructure.

Figure 1: Line graph showing Magecart e-skimmer infections in 2025, by different groups, kits, and techniques. (Source: Recorded Future)

Purchase scam operations reflect a similar dynamic. Recorded Future Payment Fraud Intelligence identified more than 3,600 scam merchant accounts in 2025, up 2.5x from 2024, spanning at least 40 countries and 230 acquirers.

Recurring patterns in merchant registration data indicate that scam operators have standardized their merchant acquisition workflows, standing up fraudulent payment infrastructure at scale through repeatable, low-friction processes.

Card testing operates on the same service-economy logic. Telegram-based card testing services validated at least 27 million card records in 2025 through public-facing card generation and testing channels that any threat actor can access.

Among dark web checker services, over 1,350 legitimate merchant accounts were abused for card testing, with 94% not observed prior to 2025, suggesting systematic rotation to stay ahead of detection.

Figure 2: Graphic illustrating the purchase scam attack chain. (Source: Recorded Future)

The Ecosystem Is Concentrated Upstream

Notably, each of these industrialized attack vectors sits upstream of the fraudulent transaction. E-skimmer infections and scam merchants compromise card data during online purchases. Card testing validates that stolen data before it’s monetized.

"Fraud outcomes are visible, but the pathways that enable them are often not."

This industrialized scale across these attack vectors requires standardization, and standardization produces detectable patterns.

When 26% of e-skimmer infections trace back to a single kit, when scam operators reuse merchant registration patterns across hundreds of acquirers, when card testers rotate through predictable BIN attack workflows, the convergence that makes fraud scalable also makes it mappable. As that standardization deepens, a single indicator of compromise reaches further across the threat landscape.

That standardization creates something concrete: a window.

Magecart infections are active and identifiable before stolen card data is harvested.
Scam merchants often display detectable signals, including recent domain registration, merchant rotation, and merchant category code mismatches.

Card testing activity reveals when a monetization attempt is likely to occur.

Each stage represents an opportunity to act before fraud registers as a financial loss.

Transaction Monitoring Looks at the Wrong End of the Lifecycle

Transaction monitoring and behavioral fraud models are built to detect anomalies at the point of payment, like unusual spend patterns, velocity, and geographic inconsistencies. They do what they were designed to, but provide no visibility into the increasingly industrialized, pre-monetization stages that were built to avoid detection by these traditional processes.

Purchase scams are explicitly designed to circumvent transaction-based controls by manipulating cardholders into authorizing the fraudulent transaction themselves, making the payment appear legitimate by design.

Card testers cycle through new merchants specifically because historical tester merchants get flagged (94% of tester merchants identified in 2025 were not previously observed). A detection approach built around transaction signals will always be working with information that arrives after the upstream infrastructure has already done its job.

As the upstream ecosystem industrializes, the volume of activity that transaction monitoring cannot see has grown. With purchase scam detections more than quadrupling year-over-year and Magecart infections having likely compromised more than 23 million transactions in 2025 alone, the cost of that blind spot compounds.

Maintaining an effective fraud posture will increasingly require financial institutions to complement reactive account monitoring with proactive, intelligence-informed defenses.

How Recorded Future Payment Fraud Intelligence Addresses This

Recorded Future Payment Fraud Intelligence monitors each of the upstream stages discussed in this post.

With daily monitoring of Magecart-infected sites and enriched merchant data that integrates with transaction monitoring, Payment Fraud Intelligence can enable detection of high-risk merchants months before stolen card data appears for sale.

Additionally, the Scam Merchants dataset can identify fraudulent merchant accounts and their associated domains before customers are defrauded and before downstream card data reaches criminal markets.

Tester merchant monitoring surfaces card testing activity as an early signal of which portfolios are being targeted ahead of any monetization attempt.

Because Payment Fraud Intelligence monitors the sources, kits, and infrastructure that threat actors have increasingly standardized around, a single identified indicator can surface exposure across a portfolio at scale.

According to Recorded Future data, 75% of compromised cards are identified before fraud occurs, and 90% of compromised card assets are identified within hours of a breach.

The pre-monetization window will not narrow as the fraud ecosystem matures — if anything, the report's data suggests it will widen as standardization deepens. Financial institutions with visibility into that window can act before losses occur. Those without it will continue to respond after the fact.

Read the full Annual Payment Fraud Intelligence Report: 2025 to explore this year's findings in depth.

The expanding conflict around Iran signals a deeper shift. We have entered an era of quantum geopolitics, where the old rules of the international order no longer apply. What began as a regional confrontation is already reshaping global markets, supply chains, and corporate security planning. Leaders must adapt how they think, spend, and communicate in a system where uncertainty is not a risk to manage—it is the operating environment itself.

What is Quantum Geopolitics?

A useful analogy comes from physics.

Classical systems produce predictable outcomes. Quantum systems behave probabilistically, where interactions in one place can produce distant effects.

International politics increasingly resembles the latter.

The assumptions that shaped corporate strategy for decades—durable alliances, expanding globalization, and broadly coherent regulation—are weakening. Geopolitical shocks now move rapidly through tightly interconnected systems.

Four dynamics define how this system now behaves.

🌓 Superposition: Friends, Rivals, and Everything in Between

Countries can no longer be neatly categorised “ally” or “adversary.” They exist in overlapping states, with true alignment revealed only in moments of crisis.

States balance security partnerships with the West while maintaining economic ties with rivals. Turkey supports Ukraine diplomatically while sustaining trade flows that benefit Russia. India deepens defence ties with the United States even as it increases purchases of Russian oil.

Public statements offer limited guidance. Trade flows, enforcement patterns, and technology controls are more reliable indicators of intent.

For multinational firms, geopolitical positioning is no longer fixed. It is fluid.

🌀 The End of Guarantees: Promises Now Come with Caveats

Security commitments, trade access, and regulatory stability have shifted from certainties to probabilities.

Export controls can reroute supply chains within months. Sanctions regimes expand or unwind quickly. Even long-standing alliances depend on political will at the moment they are tested.

For businesses, this means long-term investments now carry elevated policy risk.

Leaders must plan for variance.

🧬 Quantum Entanglement: Local Conflicts Are Not Local

Global systems—financial, technological, logistical—are tightly coupled. Regional conflicts now generate immediate global effects.

Threats to Gulf commercial hubs disrupt international banking. Instability in the Strait of Hormuz drives energy price volatility and strains global shipping insurance. Cyber campaigns tied to the conflict target companies far beyond the region.

Disruption is rarely contained. Risk can no longer be managed by geography or function alone.

🔬 The Observer Effect: Whoever Sets the Rules First Wins

Influence increasingly derives from shaping rules rather than operating within them.

States that move early to establish standards in artificial intelligence, semiconductors, digital infrastructure, and financial regulation compel others to adapt.

Waiting for clarity can therefore be a strategic liability in itself.
If you do not shape the agenda, you become subject to it.

Why This Moment Feels Different

These dynamics are most visible in cyberspace, where geopolitical competition unfolds continuously below the threshold of open conflict.

State-sponsored actors operate inside corporate networks without triggering overt confrontation. Criminal groups, proxies, and intelligence services overlap, complicating attribution and response.

The boundary between geopolitical conflict and corporate exposure is now thin. A single breach can trigger regulatory scrutiny, customer loss, market volatility, and diplomatic tension at once.

Cybersecurity is no longer a technical function. It is a core enterprise risk.

How Security Leaders Should Respond

In a system governed by probabilities rather than predictability, security leaders must adapt how they think, allocate resources, and position their organizations.

1. Mindset Shift: Scenarios, Not Forecasts

Replace long planning horizons and static risk assessments with continuous scenario planning. Tools such as the Cone of Plausibility can stress-test responses to sanctions escalation, maritime disruption, regulatory fragmentation, or supply chain shocks.

Evaluate decision speed, cross-functional coordination, and response thresholds under pressure.
Adaptability matters more than accuracy.

2. Spending Shift: Invest in Resilience, Not Just Efficiency

Systems optimized solely for efficiency often lack resilience.

Diversifying suppliers, strengthening sanctions compliance, improving cybersecurity, and increasing visibility into third-party exposure can reduce vulnerability to geopolitical shocks.

Resilience is not a defensive expense; it is operational insurance.

3. Communication Shift: From Reporting to Action

Security leaders must translate geopolitical developments into clear decision frameworks before crises materialize.

This requires close coordination across legal, finance, and operations, as well as proactive engagement with regulators and industry partners.

Speed and clarity determine whether the organization shapes outcomes or reacts to them.

Final Thoughts

The Iran conflict offers a preview of what comes next. Alliances are conditional. Economic pressure, cyber activity, and regulatory responses unfold simultaneously.

Quantum geopolitics does not eliminate strategy. It demands a different kind—one built on scenario readiness, structural resilience, and faster decision cycles.

Leaders who wait for clarity will move too late.

Those who organize for uncertainty will operate ahead of it.

To access the latest Insikt Group® research click here.

Insikt Group® helps Recorded Future secure our world with threat intelligence. With deep experience in government, law enforcement, military, and intelligence agencies, we power the Recorded Future Platform with analyst-validated data, analytics, along with cyber and geopolitical intelligence. This enables our customers to reduce risk and prevent disruption.

June 3, 2022: Original publication date of this post. This post has been updated to add the additional IAM policy types: Resource control policies.

You manage access in AWS by creating policies and attaching them to AWS Identity and Access Management (IAM) principals (roles, users, or groups of users) or AWS resources. AWS evaluates these policies when an IAM principal makes a request, such as uploading an object to an Amazon Simple Storage Service (Amazon S3) bucket. Permissions in the policies determine whether the request is allowed or denied. While IAM operates primarily at the individual AWS account level, organizations with multiple AWS accounts can extend these access controls through AWS Organizations, which provides additional policy types that work alongside IAM to enforce governance and security standards across their entire organizational structure. By using AWS Organizations, you can group accounts in the multi-account environment into organizational units (OUs), apply policy-based controls across these groups.

In this blog post, you will learn how to select the appropriate policy types for your security requirements and determine which team should own and manage each policy. You will explore seven policy types—including identity-based policies, resource-based policies, permissions boundaries, service control policies (SCPs), and resource control policies (RCPs)—through a practical scenario involving multiple AWS accounts and teams.

Different policy types and when to use them

AWS has different policy types that provide you with powerful flexibility, and it’s important to know how and when to use each policy type. It’s also important for you to understand how to structure your IAM policy ownership to avoid a centralized team from becoming a bottleneck. Explicit policy ownership can allow your teams to move more quickly, while staying within the secure guardrails that are defined centrally.

Service control policies overview

Service control policies (SCPs) are a feature of AWS Organizations. AWS Organizations is a service for grouping and centrally managing the AWS accounts that your business owns. SCPs are policies that specify the maximum permissions for an organization, organizational unit (OU), or an individual account. An SCP can limit permissions for principals in member accounts, including the AWS account root user.

SCPs are meant to be used as coarse-grained guardrails, and they don’t directly grant access. The primary function of SCPs is to enforce security invariants across AWS accounts and OUs in an organization. Security invariants are control objectives or configurations that you apply to multiple accounts, OUs, or the whole organization managed by AWS Organizations. For example, you can use an SCP to prevent member accounts from leaving your organization or to enforce that AWS resources can only be deployed to certain AWS Regions.

Resource control policies overview

Resource control policies (RCPs) are an AWS Organizations feature to manage permissions centrally. RCPs set the maximum available permissions for resources across your organization. RCPs help ensure that resources in your accounts stay within your organization’s access control guidelines.

RCPs are typically used to enforce data perimeter controls to prevent accidental data sharing outside your organization and to control resource sharing and cross-account access patterns centrally. You can also use RCPs to implement security controls for sensitive resources across your organization’s accounts and to add an additional layer of protection for resources such as S3 buckets that store confidential data.

Note: SCPs are principal-centric controls that specify which services your IAM users and IAM roles can access, which resources they can access, or the conditions under which they can make requests (for example, from specific Regions or networks). On the other hand, RCPs are resource-centric controls that can restrict access to your resources so that they can be accessed only by identities that belong to your organization or specify the conditions under which identities external to your organization can access your resources. To understand SCPs and RCPs differences and use cases, see General use cases for SCPs and RCPs.

Permissions boundaries overview

Permissions boundaries are an advanced IAM feature in which you set the maximum permissions that an identity-based policy can grant to an IAM principal. When you set a permissions boundary for a principal, the principal can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries.

A permissions boundary is a type of identity-based policy that doesn’t directly grant access. Instead, like an SCP, a permissions boundary acts as a guardrail for your IAM principals that allows you to set coarse-grained access controls. A permissions boundary is typically used to delegate the creation of IAM principals. Delegation enables other individuals in your accounts to create new IAM principals, but limits the permissions that can be granted to the new IAM principals.

Identity-based policies overview

Identity-based policies are policy documents that you attach to a principal (roles, users, and groups of users) to control what actions a principal can perform, on which resources, and under what conditions. Identity-based policies can be further categorized into AWS managed policies, customer managed policies, and inline policies. AWS managed policies are reusable identity-based policies that are created and managed by AWS. You can use AWS managed policies as a starting point for building your own identity-based policies that are specific to your organization. Customer managed policies are reusable identity-based policies that can be attached to multiple identities. Customer managed policies are useful when you have multiple principals with identical access requirements. Inline policies are identity-based policies that are attached to a single principal. Use inline-policies when you want to create least-privilege permissions that are specific to a particular principal.

You will have many identity-based policies in your AWS account that are used to enable access in scenarios such as human access, application access, machine learning workloads, and deployment pipelines. These policies should be fine-grained. You use these policies to directly apply least privilege permissions to your IAM principals. You should write the policies with permissions for the specific task that the principal needs to accomplish.

Resource-based policies overview

Resource-based policies are policy documents that you attach to a resource such as an S3 bucket. These policies grant the specified principal permission to perform specific actions on that resource and define under what conditions this permission applies. Resource-based policies are inline policies. For a list of AWS services that support resource-based policies, see AWS services that work with IAM.

Resource-based policies are optional for many workloads that don’t span multiple AWS accounts. Fine-grained access within a single AWS account is typically granted with identity-based policies. AWS Key Management Service (AWS KMS) keys and IAM role trust policies are two exceptions, and both of these resources must have a resource-based policy even when the principal and the KMS key or IAM role are in the same account. IAM roles and KMS keys behave this way as an extra layer of protection that requires the owner of the resource (key or role) to explicitly allow or deny principals from using the resource. For other resources that support resource-based policies, here are some examples where they are most commonly used:

1. Granting cross-account access to your AWS resource.
2. Granting an AWS service access to your resource when the AWS service uses an AWS service principal. For example, when using AWS CloudTrail, you must explicitly grant the CloudTrail service principal access to write files to an Amazon S3 bucket.
3. Applying broad access guardrails to your AWS resources. You can see some examples in the blog post IAM makes it easier for you to manage permissions for AWS services accessing your resources.
4. Applying an additional layer of protection for resources that store sensitive data, such as AWS Secrets Manager secrets or an S3 bucket with sensitive data. You can use a resource-based policy to deny access to IAM principals that shouldn’t have access to sensitive data, even if granted access by an identity-based policy. An explicit deny in an IAM policy always overrides an allow.

How to implement different policy types

In this section, we will walk you through an example of a design that includes all four of the policy types explained in this post.

The example that follows shows an application that runs on an Amazon Elastic Compute Cloud (Amazon EC2) instance and needs to read from and write files to an S3 bucket in the same account. The application also reads (but doesn’t write) files from an S3 bucket in a different account. The company in this example, Example Corp, uses a multi-account strategy, and each application has its own AWS account. The architecture of the application is shown in Figure 1.

Figure 1: Sample application architecture that needs to access S3 buckets in two different AWS accounts

There are three teams that participate in this example: the Central Cloud Team, the Application Team, and the Data Lake Team. The Central Cloud Team is responsible for the overall security and governance of the AWS environment across all AWS accounts at Example Corp. The Application Team is responsible for building, deploying, and running their application within the application account (111111111111) that they own and manage. Likewise, the Data Lake Team owns and manages the data lake account (222222222222) that hosts a data lake at Example Corp.

With that background in mind, we will walk you through an implementation for each of the four policy types and include an explanation of which team we recommend own each policy. The policy owner is the team that is responsible for creating and maintaining the policy.

Service control policies

The Central Cloud Team owns the implementation of the security controls that should apply broadly to all of Example Corp’s AWS accounts. At Example Corp, the Central Cloud Team has two security requirements that they want to apply to all accounts in their organization:

1. AWS API calls should be encrypted in transit to maintain security best practices
2. Accounts can’t leave the organization on their own.

The Central Cloud Team chooses to implement these security invariants using SCPs and applies the SCPs to the root of the organization. The first statement in Policy 1 denies all requests that are not sent using SSL (TLS). The second statement in Policy 1 prevents an account from leaving the organization.

This is only a subset of the SCP statements that Example Corp uses. Example Corp uses a deny list strategy, and there must also be an accompanying statement with an Effect of Allow at every level of the organization that isn’t shown in the SCP in Policy 1.

Policy 1: SCP attached to AWS Organizations organization root

{
		"Id": "ServiceControlPolicy",
		"Version": "2012-10-17",
		"Statement": [{
			"Sid": "DenyIfRequestIsNotUsingSSL",
			"Effect": "Deny",
			"Action": "*",
			"Resource": "*",
			"Condition": {
				"BoolIfExists": {
					"aws:SecureTransport": "false"
				}
			}
	},
	{
		"Sid": "PreventLeavingTheOrganization",
		"Effect": "Deny",
		"Action": "organizations:LeaveOrganization",
		"Resource": "*"
	}]
}

Resource control policies

The Central Cloud Team also has three additional security requirements for Amazon S3 resource deployment to accounts.

1. Require a minimum TLS version of 1.2 for S3 bucket access
2. Mandate encryption of S3 objects using AWS Key Management Service (AWS KMS)
3. Deny S3 access from AWS account outside the organization managed by AWS Organizations

The Central Cloud Team attaches the RCPs to the root of the organization, following the same approach used for SCPs, so that the policy applies across all accounts.
Policy 2 enforces three controls across S3 buckets in the organization. The first statement requires TLS 1.2 for data-in-transit. The second statement requires AWS KMS encryption for data-at-rest. The third statement restricts S3 bucket access to principals from accounts within the organization (identified by example-corp-organization-id), blocking access from external accounts.

Policy 2: RCP attached to the organization root to enforce data perimeter

{
  "Id": "ResourceControlPolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceS3TLSVersion",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "NumericLessThan": {
          "s3:TlsVersion": [
            "1.2"
          ]
        }
      }
    },
    {
      "Sid": "EnforceKMSEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
        }
      }
    },
    {
      "Sid": "DenyAllExternalS3Access",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalOrgID": "example-corp-organization-id"
        }
      }
    }
  ]
}

Permissions boundary policies

The Central Cloud Team wants to make sure that they don’t become a bottleneck for the Application Team. They want to allow the Application Team to deploy their own IAM principals and policies for their applications. The Central Cloud Team also wants to make sure that any principals created by the Application Team can only use AWS APIs that the Central Cloud Team has approved.

At Example Corp, the Application Team deploys to their production AWS environment through a continuous integration/continuous deployment (CI/CD) pipeline. The pipeline itself has broad access to create AWS resources needed to run applications, including permissions to create additional IAM roles. The Central Cloud Team implements a control that requires that all IAM roles created by the pipeline must have a permissions boundary attached. This allows the pipeline to create additional IAM roles, but limits the permissions that the newly created roles can have to what is allowed by the permissions boundary. This delegation strikes a balance for the Central Cloud Team. They can avoid becoming a bottleneck to the Application Team by allowing the Application Team to create their own IAM roles and policies, while ensuring that those IAM roles and policies are not overly privileged.

An example of the permissions boundary policy that the Central Cloud Team attaches to IAM roles created by the CI/CD pipeline is shown below. This same permissions boundary policy can be centrally managed and attached to IAM roles created by other pipelines at Example Corp. The policy describes the maximum possible permissions that additional roles created by the Application Team are allowed to have, and it limits those permissions to some Amazon S3 and Amazon Simple Queue Service (Amazon SQS) data access actions. It’s common for a permissions boundary policy to include data access actions when used to delegate role creation. This is because most applications only need permissions to read and write data (for example, writing an object to an S3 bucket or reading a message from an SQS queue) and only sometimes need permission to modify infrastructure (for example, creating an S3 bucket or deleting an SQS queue). As Example Corp adopts additional AWS services, the Central Cloud Team updates this permissions boundary with actions from those services.

Policy 3: Permissions boundary policy attached to IAM roles created by the CI/CD pipeline

{
  "Id": "PermissionsBoundaryPolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "sqs:ChangeMessageVisibility",
        "sqs:DeleteMessage",
        "sqs:ReceiveMessage",
        "sqs:SendMessage",
        "sqs:PurgeQueue",
        "sqs:GetQueueUrl",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

In the next section, you will learn how to enforce that this permissions boundary is attached to IAM roles created by your CI/CD pipeline.

Identity-based policies

In this example, teams at Example Corp are only allowed to modify the production AWS environment through their CI/CD pipeline. Write access to the production environment is not allowed otherwise. To support the different personas that need to have access to an application account in Example Corp, three baseline IAM roles with identity-based policies are created in the application accounts:

• A role for the CI/CD pipeline to use to deploy application resources.
• A read-only role for the Central Cloud Team, with a process for temporary elevated access.
• A read-only role for members of the Application Team.

All three of these baseline roles are owned, managed, and deployed by the Central Cloud Team.

The Central Cloud Team is given a default read-only role (CentralCloudTeamReadonlyRole) that allows read access to all resources within the account. This is accomplished by attaching the AWS managed ReadOnlyAccess policy to the Central Cloud Team role. You can use the IAM console to attach the ReadOnlyAccess policy, which grants read-only access to all services. When a member of the team needs to perform an action that is not covered by this policy, they follow a temporary elevated access process to make sure that this access is valid and recorded.

A read-only role is also given to developers in the Application Team (DeveloperReadOnlyRole) for analysis and troubleshooting. At Example Corp, developers are allowed to have read-only access to Amazon EC2, Amazon S3, Amazon SQS, AWS CloudFormation, and Amazon CloudWatch. Your requirements for read-only access might differ. Several AWS services offer their own read-only managed policies, and there is also the previously mentioned AWS managed ReadOnlyAccess policy that grants read only access to all services. To customize read-only access in an identity-based policy, you can use the AWS managed policies as a starting point and limit the actions to the services that your organization uses. The customized identity-based policy for Example Corp’s DeveloperReadOnlyRole role is shown below.

Policy 4: Identity-based policy attached to a developer read-only role to support human access and troubleshooting

{
  "Id": "DeveloperRoleBaselinePolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudformation:Describe*",
        "cloudformation:Get*",
        "cloudformation:List*",
        "cloudwatch:Describe*",
        "cloudwatch:Get*",
        "cloudwatch:List*",
        "ec2:Describe*",
        "ec2:Get*",
        "ec2:List*",
        "ec2:Search*",
        "s3:Describe*",
        "s3:Get*",
        "s3:List*",
        "sqs:Get*",
        "sqs:List*",
        "logs:Describe*",
        "logs:FilterLogEvents",
        "logs:Get*",
        "logs:List*",
        "logs:StartQuery",
        "logs:StopQuery"
      ],
      "Resource": "*"
    }
  ]
}

The CI/CD pipeline role has broad access to the account to create resources. Access to deploy through the CI/CD pipeline should be tightly controlled and monitored. The CI/CD pipeline is allowed to create new IAM roles for use with the application, but those roles are limited to only the actions allowed by the previously discussed permissions boundary. The roles, policies, and EC2 instance profiles that the pipeline creates should also be restricted to specific role paths. This enables you to enforce that the pipeline can only modify roles and policies or pass roles that it has created. This helps prevent the pipeline, and roles created by the pipeline, from elevating privileges by modifying or passing a more privileged role. Pay careful attention to the role and policy paths in the Resource element of the following CI/CD pipeline role policy (Policy 5). The CI/CD pipeline role policy also provides some example statements that allow the passing and creation of a limited set of service-linked roles (which are created in the path /aws-service-role/). You can add other service-linked roles to these statements as your organization adopts additional AWS services.

Policy 5: Identity-based policy attached to CI/CD pipeline role

{
  "Id": "CICDPipelineBaselinePolicy",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "sqs:*",
        "s3:*",
        "cloudwatch:*",
        "cloudformation:*",
        "logs:*",
        "autoscaling:*"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "ssm:GetParameter*",
      "Resource": "arn:aws:ssm:*::parameter/aws/service/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:PutRolePolicy",
        "iam:DeleteRolePolicy"
      ],
      "Resource": "arn:aws:iam::111111111111:role/application-roles/*",
      "Condition": {
        "ArnEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::111111111111:policy/PermissionsBoundary"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:DetachRolePolicy"
      ],
      "Resource": "arn:aws:iam::111111111111:role/application-roles/*",
      "Condition": {
        "ArnEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::111111111111:policy/PermissionsBoundary"
        },
        "ArnLike": {
          "iam:PolicyARN": "arn:aws:iam::111111111111:policy/application-role-policies/*"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:DeleteRole",
        "iam:TagRole",
        "iam:UntagRole",
        "iam:GetRole",
        "iam:GetRolePolicy"
      ],
      "Resource": "arn:aws:iam::111111111111:role/application-roles/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreatePolicy",
        "iam:DeletePolicy",
        "iam:CreatePolicyVersion",
        "iam:DeletePolicyVersion",
        "iam:GetPolicy",
        "iam:TagPolicy",
        "iam:UntagPolicy",
        "iam:SetDefaultPolicyVersion",
        "iam:ListPolicyVersions"
      ],
      "Resource": "arn:aws:iam::111111111111:policy/application-role-policies/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:CreateInstanceProfile",
        "iam:AddRoleToInstanceProfile",
        "iam:RemoveRoleFromInstanceProfile",
        "iam:DeleteInstanceProfile"
      ],
      "Resource": "arn:aws:iam::111111111111:instance-profile/application-instance-profiles/*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": [
        "arn:aws:iam::111111111111:role/application-roles/*",
        "arn:aws:iam::111111111111:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "iam:CreateServiceLinkedRole",
      "Resource": "arn:aws:iam::111111111111:role/aws-service-role/*",
      "Condition": {
        "StringEquals": {
          "iam:AWSServiceName": "autoscaling.amazonaws.com"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "iam:DeleteServiceLinkedRole",
        "iam:GetServiceLinkedRoleDeletionStatus"
      ],
      "Resource": "arn:aws:iam::111111111111:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:ListRoles",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:GetRole",
      "Resource": [
        "arn:aws:iam::111111111111:role/application-roles/*",
        "arn:aws:iam::111111111111:role/aws-service-role/*"
      ]
    }
  ]
}

In addition to the three baseline roles with identity-based policies in place that you’ve seen so far, there’s one additional IAM role that the Application Team creates using the CI/CD pipeline. This is the role that the application running on the EC2 instance will use to get and put objects from the S3 buckets in Figure 1. Explicit ownership allows the Application Team to create this identity-based policy that fits their needs without having to wait and depend on the Central Cloud Team. Because the CI/CD pipeline can only create roles that have the permissions boundary policy attached, Policy 6 cannot grant more access than the permissions boundary policy allows (Policy 3).

If you compare the identity-based policy attached to the EC2 instance’s role (Policy 6 on left) with the permissions boundary policy described previously (Policy 3 on the right), you can see that the actions allowed by the EC2 instance’s role are also allowed by the permissions boundary policy. Actions must be allowed by both policies for the EC2 instance to perform the s3:GetObject and s3:PutObject actions. Access to create a bucket would be denied even if the role attached to the EC2 instance was given permission to perform the s3:CreateBucket action because the s3:CreateBucket action exceeds the permissions allowed by the permissions boundary.

Policy 6: Identity-based policy bound by permissions boundary and attached to the application’s EC2 instance { "Id": "ApplicationRolePolicy", "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject" ], "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET1/*" }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET2/*" } ] }

Policy 3: Permissions boundary policy attached to IAM roles created by the CI/CD pipeline. { "Id": "PermissionsBoundaryPolicy", "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "sqs:ChangeMessageVisibility", "sqs:DeleteMessage", "sqs:ReceiveMessage", "sqs:SendMessage", "sqs:PurgeQueue", "sqs:GetQueueUrl", "logs:PutLogEvents" ], "Resource": "*" } ] }

Resource-based policies
The only resource-based policy needed in this example is attached to the bucket in the account external to the application account (DOC-EXAMPLE-BUCKET2 in the data lake account in Figure 1). Both the identity-based policy and resource-based policy must grant access to an action on the S3 bucket for access to be allowed in a cross-account scenario. The bucket policy below only allows the GetObject action to be performed on the bucket, regardless of what permissions the application’s role (ApplicationRole) is granted from its identity-based policy (Policy 6).

This resource-based policy is owned by the Data Lake Team that owns and manages the data lake account (222222222222) and the policy (Policy 7). This allows the Data Lake Team to have complete control over what teams external to their AWS account can access their S3 bucket.

Policy 7: Resource-based policy attached to S3 bucket in external data lake account (222222222222)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:role/application-roles/ApplicationRole"
      },
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET2/*"
    }
  ]
}

No resource-based policy is needed on the S3 bucket in the application account (DOC-EXAMPLE-BUCKET1 in Figure 1). Access for the application is granted to the S3 bucket in the application account by the identity-based policy. Access can be granted by either an identity-based policy or a resource-based policy when access is within the same AWS account.

Putting it all together

Figure 2 shows the architecture and includes the different policies and the resources they are attached to. The table that follows summarizes the various IAM policies that are deployed to the Example Corp AWS environment, and specifies what team is responsible for each of the policies.

Figure 2: Sample application architecture with CI/CD pipeline used to deploy infrastructure

The numbered policies in Figure 2 correspond to the policy numbers in the following table.

Policy number	Policy description	Policy type	Policy owner	Attached to
1	Enforce SSL and prevent member accounts from leaving the organization for all principals in the organization	Service control policy (SCP)	Central Cloud Team	Organization root
2	Enforce TLS 1.2 and KMS encryption for S3 buckets across the organization	Resource control policy (RCP)	Central Cloud Team	Organization root
3	Restrict maximum permissions for roles created by CI/CD pipeline	Permissions boundary	Central Cloud Team	All roles created by the pipeline (ApplicationRole)
4	Scoped read-only policy	Identity-based policy	Central Cloud Team	IAM role
5	CI/CD pipeline policy	Identity-based policy	Central Cloud Team	IAM role
6	Policy used by running application to read and write to S3 buckets	Identity-based policy	Application Team	on EC2 instance
7	Bucket policy in data lake account that grants access to a role in application account	Resource-based policy	Data Lake Team	S3 Bucket in data lake account
8	Broad read-only policy	Identity-based policy	Central Cloud Team	IAM role

Conclusion
In this blog post, you learned about four different policy types: identity-based policies, resource-based policies, service control policies (SCPs), resource control polices (RCPs), permissions boundary policies, and resource control policies. You saw examples of situations where each policy type is commonly applied. Then, you walked through a real-life example that describes an implementation that uses these policy types.

By implementing multiple IAM policy types in a layered approach, you can achieve robust access control that follows the principle of least privilege while enabling team autonomy. This defense-in-depth strategy helps prevent unauthorized access through multiple policy evaluation checkpoints.

You can use this blog post as a starting point for developing your organization’s IAM strategy. You might decide that you don’t need all of the policy types explained in this post, and that’s OK. Not every organization needs to use every policy type. You might need to implement policies differently in a production environment than a sandbox environment. The important concepts to take away from this post are the situations where each policy type is applicable, and the importance of explicit policy ownership. We also recommend taking advantage of policy validation in AWS IAM Access Analyzer when writing IAM policies to validate your policies against IAM policy grammar and best practices.

For more information, including the policies described in this solution and the sample application, see the how-and-when-to-use-aws-iam-policy-blog-samples GitHub repository. The repository walks through an example implementation using a CI/CD pipeline with AWS CodePipeline.If you have any questions, please post them in the AWS Identity and Access Management re:Post topic or reach out to AWS Support.