Cybersecurity Awareness Month has a simple message for October 2026: Don’t Make It Easy for Them.
The National Cybersecurity Alliance (NCA) is encouraging you to build a few basic security habits into your everyday life: use strong passwords and a password manager, turn on multifactor authentication, recognize and report scams, and keep software updated.
None of these actions make you immune from attack. But that isn’t their point. Each removes an easy route and forces any attacker to work harder. This is becoming increasingly important as attackers leverage AI to enhance their phishing and vishing campaigns, make more realistic deepfakes, create evasive malware, and automate reverse engineering.
The same principle applies to the applications people rely on. Users can protect their passwords, update their devices, and learn to spot scams. What they can’t do is stop an attacker from downloading an app, pulling it apart, studying its code, attaching debugging and instrumentation tools, trying to manipulate how it behaves at runtime, or from tricking a user into downloading a modified app that installs malware.
Protecting the application itself is a different security problem. Responsibility for making it harder to analyze, manipulate, and abuse sits with the organizations building and operating those applications, as well as any interconnected APIs, integrated SDKs, and embedded AI models.
There's an economic angle to cybersecurity that's often overlooked in favour of a purely technical viewpoint. It comes down to this insight: attackers have costs too.
Attackers invest time understanding a target. They need tools, infrastructure, expertise, and working attack paths. Once they find a technique that works, they look for ways to repeat and automate it. Emerging threats also include use of agents and subagents for reconnaissance and for creating attacks on the fly.
AI lowers the cost of many of those investments. For example, in When mobile and AI collide: Why app security can’t reuse the web playbook, we looked at how AI can reduce the effort required for reconnaissance, code interpretation, tooling, debugging, and adapting attack sequences. An attacker doesn’t need AI to invent a new class of attack. Moving through familiar attack steps faster already changes the economics of an attack.
The same shift is now visible in vulnerability discovery. Anthropic reported that Claude Opus 4.6 found 22 vulnerabilities in Firefox over two weeks, while OpenAI says its Patch the Planet work with Trail of Bits identified hundreds of security issues across 19 open-source projects. In one testing workflow, AI-assisted work produced results within days that would historically have taken weeks or months. These are defensive programs, but they show how frontier LLMs can compress the time and expertise involved in finding and validating software flaws.
AI cost reduction gives defenders a clear problem to address, and a challenge to overcome. AI and automation lower the cost of reconnaissance, analysis, vulnerability discovery, and attack development. So how can we push the attacker’s cost back up? The answer is that runtime protection can heighten it again.
Raising that cost doesn’t depend on making an app impossible to attack. That’s a vital point to grasp. Rather, the goal is to make useful progress harder, slower, less reliable, and easier to detect.
An application enters a different security environment once it is released. Attackers can obtain the same application package as any legitimate user or interact with it freely over the Internet using a web browser.
From that point on, attackers can inspect it on their own device, uncover intellectual property or critical business logic, and observe how the application or backend APIs respond. Security controls need to account for what happens after deployment.
Several runtime protection techniques can make the released application harder to analyze, manipulate, and abuse.
Code obfuscation and encryption make static analysis harder.
Anti-debugging and anti-tampering controls interfere with common analysis techniques.
Runtime integrity checks detect manipulation.
Application shielding makes instrumentation, repackaging, hooking, and other forms of runtime interference more expensive to carry out at scale.
Attestation ensures only trusted clients can access back-end APIs
Our recent post DEX encryption done right: Raising the bar for Android attackers shows what this looks like at one technical layer. DEX encryption changes the attacker’s starting point by preventing packaged Android bytecode from being directly readable. Not every route to the code is removed. But DEX encryption adds work and forces the attacker toward more difficult forms of analysis.
Effective security puts multiple barriers in the attacker’s path, each adding time, effort, and uncertainty. Each control can increase the amount of knowledge, tooling, or manual effort required to reach the next stage.
Economics will continue to rise in importance as attack tooling improves. As we argued in AI-powered mobile app attacks: What app shielding can and can’t stop, AI can lower the expertise barrier around tasks such as reconnaissance, reverse engineering, vulnerability exploit chaining, scripting, and malicious automation. Shielding works in the opposite direction: increasing uncertainty, disrupting common tooling, and frustrating the attacker through a layered defense-in-depth approach.
An attacker who encounters a runtime protection that blocks or disrupts their current approach doesn’t necessarily stop there. They observe what happens, change their approach, and try again. We as defenders need a similar feedback loop.
Security decisions that require an immediate response need to happen locally, inside the application. Others benefit from what can be learned across applications, devices, attacks, and time. This is the idea behind the Protect → Collect → Analyze → Adapt runtime intelligence loop.
Protection makes attacks harder and generates evidence about what is happening inside protected applications. This runtime information is then analyzed centrally to identify patterns and improve detection. What we learn can then inform protection closer to where the attack starts: inside the application, on the user’s device, within the client browser.
We explored this model in more depth in Learn globally, act locally: Why app security needs a runtime intelligence loop. It doesn’t replace local protection with a cloud decision. An application may need to respond immediately, with no reliable network connection and before a backend request takes place. But the wider intelligence layer helps those local protections improve over time.
Raise the barrier. See how attackers respond. Learn. Raise it again. Continuously layer defenses to remove the attack surface.
Cybersecurity Awareness Month is built around actions you can take yourself. Stronger authentication, better passwords, scam awareness, and regular updates all remove opportunities that attackers would otherwise exploit.
Application providers have a parallel responsibility. Once software leaves the development environment, assume it ends up in a hostile environment where hackers can get hold of it. Protect the code, logic, and secrets that need to remain inside it. Detect attempts to manipulate its runtime. Protect backend infrastructure from abuse. Use what protected applications see to understand how attacks are changing.
No, you can’t control every environment in which your application runs. But the good news is you can control how easy you make the attacker’s job, and we can help you with that.
Click here for more on the NCA and their campaign to make life difficult for cybercriminals.