How Can MSPs Become Part of a Cyberattack?

Geplaatst op: 15 October 2026

Managed service providers are a prime target for cybercriminals, and that is no coincidence. A successful attack on a single MSP gives attackers immediate access to dozens or even hundreds of client environments at once. That makes an MSP not only attractive, but also particularly vulnerable: the impact of a single breach reaches far beyond the organization itself.

In this article you will find a step-by-step breakdown of what a cyberattack on an MSP looks like, where the weakest links in your environment are, and what you can concretely do to strengthen your defenses. Whether you are just starting to improve your MSP cybersecurity or want to sharpen your existing approach, this guide offers a practical starting point.

How cybercriminals use an MSP as a gateway

Understanding how an attacker thinks is the first step toward a better defense. Cybercriminals do not choose their target at random. They look for the place where a single breach causes the most damage, and an MSP fits that picture perfectly. By compromising one MSP, an attacker gains access to the systems, networks, and data of all connected clients. That is the core of a supply chain attack via an MSP.

An attacker rarely starts by firing off exploits. During the reconnaissance phase, they first examine the structure of the organization: which vendors have access, which identities exist, what permissions accounts hold, and what gaps exist between the security measures in place. Only once they have a clear picture of the environment do they choose their attack path. The most common entry points at an MSP are:

• Compromised administrator accounts with excessive privileges
• Insufficiently secured remote access tools such as RMM software
• Weak or reused passwords without multi-factor authentication
• Outdated software with known vulnerabilities
• Insecure API connections to client environments

What makes this extra dangerous is that attackers do not look at individual findings. They see attack paths: combinations of multiple small weaknesses that together lead to full access. A misconfiguration in Azure, combined with excessive permissions and a weak identity, can escalate step by step to complete control over a cloud subscription. Each component on its own may seem low risk; together they form a critical vulnerability.

Identify the weakest links in your MSP environment

Now that you know how attackers operate, the next step is mapping your own vulnerabilities. Many MSPs think they are secure because they have run a vulnerability scan or worked through a list of findings. But a list of resolved CVEs says little about how secure you actually are. The real risks often lie deeper.

Work through your analysis across three levels, from simple to complex:

1. Known vulnerabilities (Layer 1): Verify that patches have been applied correctly and known CVEs have been remediated. This is the baseline layer every MSP must have in order.
2. Individual weaknesses (Layer 2): Investigate incorrect cloud configurations, excessive permissions, identity weaknesses, and insecure application settings. These are often missed by automated scanners.
3. Correlated attack paths (Layer 3): Map out what happens when you combine multiple small weaknesses. Only at this level do you see how an attacker truly operates.

Conduct an internal audit that specifically examines which accounts have access to client environments, how that access is configured, and whether unnecessary privileges exist. Also document which external parties and tools connect to your infrastructure. Insight into your attack surface starts with fully mapping everything that is connected.

Ask yourself the following questions:

• Which accounts have administrator rights they do not need?
• Are all remote access tools protected with MFA?
• Which client environments are reachable from a single compromised account?
• Are there misconfigurations in your cloud platform that could escalate access?

Simulate an attack to expose blind spots

An internal audit gives you a good starting point, but does not expose everything. To know whether your environment can withstand a real attack, you need to simulate that attack. This is where a professional pentest or red team exercise becomes indispensable. An automated vulnerability scan finds known CVEs, but a human ethical hacker thinks like an attacker and discovers the combinations of weaknesses that tools systematically miss.

Carry out the simulation in layered steps:

1. External reconnaissance: Investigate what an attacker can see from the internet, including open ports, public services, and visible technology stacks.
2. Access attempt: Try to gain access through realistic methods, such as phishing, password attacks, or abuse of remote tools.
3. Privilege escalation: Once you have a foot in the door, investigate how far you can get with the access obtained. Can you move from one account into client environments?
4. Lateral movement: Test whether segmentation works. Can an attacker move from one client environment to another?

After the simulation you will have a realistic picture of your actual attack surface. Not only which vulnerabilities exist, but also which attack paths an attacker can realistically follow. Red teaming goes further than a standard pentest: a simulated attacker attempts to break in by every possible means, including social engineering and physical access attempts.

Strengthen access control and segmentation step by step

With the findings from your simulation in hand, you can take targeted action. The most impactful improvements for an MSP almost always lie in the areas of access control and network segmentation. This is also where the greatest opportunity for attackers exists, so this is where you must start.

Implement the following measures in order of priority:

1. Implement the principle of least privilege: Every account receives only the permissions that are strictly necessary for the task. Remove all unnecessary administrator rights.
2. Enable MFA on all accounts: Without exception, including service accounts and accounts that have access to client environments.
3. Segment client environments: Ensure that a compromised account in one client environment does not grant access to other clients. Use separate credentials and network segments per client.
4. Restrict and monitor remote access: Use only approved RMM tools, enforce strict access controls, and log all sessions.
5. Remediate misconfigurations in the cloud: Review Azure or other cloud platform settings for overly permissive roles, unsecured storage, and incorrect identity settings.

After each change, verify that the measure has actually produced the intended effect. An access rule that looks correct on paper may behave differently in practice than expected. Test each adjustment before moving on to the next step.

Validate your defenses with continuous monitoring

Strengthening access control and segmentation is not a one-time action. Your environment changes constantly: new applications are added, accounts are created, permissions are adjusted, and new vulnerabilities are discovered. An annual pentest gives you a snapshot, but says nothing about how secure you are for the remaining 364 days.

Establish a structural monitoring process to validate your defenses:

1. Monitor access logs continuously: Set up alerting for anomalous behavior, such as login attempts outside business hours, unusual locations, or privilege escalation.
2. Repeat vulnerability analyses after every significant change: New cloud resources, new applications, or changed permissions require a fresh assessment.
3. Conduct periodic attack simulations: Not just annually, but aligned with the pace of change in your environment.
4. Evaluate attack paths, not just individual findings: After each round, verify that the combinations of weaknesses previously identified as risks have actually been resolved.

The goal of continuous monitoring is not to produce reports, but to maintain insight. Continuous testing and monitoring ensures that you not only know how secure you were on the test day, but also how secure you are while attackers develop new techniques. Verify your defenses by regularly checking whether the attack paths identified earlier are still closed, even after your environment has changed.

How Q-Cyber helps secure your MSP

As an MSP you carry a special responsibility: your security is in effect also the security of all your clients. We at Q-Cyber understand that responsibility and have specifically tailored our services to the challenges MSPs face. We help you not only find vulnerabilities, but also understand how attackers combine them into working attack paths.

What we concretely do for you:

• Manual pentests in which our ethical hackers think like a real attacker and expose correlated attack paths that automated tools miss
• Red team exercises in which we carry out a full attack simulation, including social engineering and escalation scenarios specifically for MSP environments
• Continuous-Q®, our program for ongoing security, in which we follow your environment after a thorough baseline pentest and flag new risks as soon as they emerge
• Independent advice on access control, segmentation, and cloud configurations, without dependency on software vendors or other suppliers

Want to know how vulnerable your MSP environment really is? Contact us for a no-obligation conversation and discover where the greatest risks lie for your organization and your clients.

Lees meer

Do You Need to Retest After a Major Software Release?

Geplaatst op: 15 October 2026

Yes, in most cases you need to retest after a major software release. A pentest is a snapshot in time: as soon as the software changes, the attack surface changes too. New features, modified authentication logic, or updated API integrations can introduce vulnerabilities that didn’t exist at the time of the previous test. The questions below help you determine when, how, and how often you need to do this.

Which changes in a release justify a new pentest?

Not every software update calls for a full new penetration test, but certain changes expand the attack surface to such an extent that testing becomes necessary. Think of new authentication or authorization logic, new external integrations or API connections, changes in how data is stored or processed, and new user roles with associated permissions. For these types of releases, retesting is not a luxury but a requirement.

A useful rule of thumb: ask yourself whether an attacker has different opportunities with the new release than before. If the answer is yes, that justifies a new test. Concrete examples of release changes that almost always require a pentest after a software release:

• New login methods or SSO integrations
• Addition of payment functionality or integrations with financial systems
• Changes to cloud configurations or infrastructure (for example new Azure roles or S3 buckets)
• Expansion of the system to new user groups or external parties
• Migrations to a new technology stack or framework

Minor bug fixes or purely visual changes generally do not justify a full pentest. But even then, a targeted vulnerability scan can be useful to check whether any unintended side effects have occurred.

How does a delta pentest differ from a full pentest?

A delta pentest focuses exclusively on the changes relative to a previously tested version of the software. A full pentest reassesses the entire system, including components that have not changed. The difference lies in scope, turnaround time, and cost: a delta pentest is faster and cheaper, but assumes that the previously tested components are still secure.

That last assumption carries risks. Even unchanged components can become vulnerable due to new attack techniques, modified dependencies, or a different environment. A delta pentest is therefore most suitable when:

• The previous full pentest was conducted recently (preferably no more than six months ago)
• The changes are well documented and clearly defined
• No major infrastructural changes have taken place alongside the release

Are there doubts about the scope of the changes, or has the previous test been some time ago? Then a full penetration test is preferable. A delta pentest saves time and money, but should never become an excuse to test less thoroughly than the situation requires.

Why is an annual pentest insufficient after frequent releases?

An annual pentest is insufficient when an organisation deploys software multiple times a year, because each new release potentially introduces new vulnerabilities. The test results from January are already outdated by June if five releases have taken place in the meantime. An annual penetration test then provides nothing more than a snapshot of a moving target.

Cybercriminals do not operate on an annual schedule. They continuously scan for new weaknesses, including in software that has just been released. Organisations that release regularly but only test once a year run an elevated risk for most months of the year without knowing it.

The problem grows as releases become more frequent. Teams working with agile or DevOps methodologies can deploy changes weekly or even daily. In that context, the question is not whether you should test more often, but how you organise that structurally. Continuous penetration testing provides an answer: instead of an annual snapshot, you create an ongoing picture of your security posture, aligned with the pace of your development cycle.

What is the difference between a pentest and a vulnerability scan after a release?

A vulnerability scan after a release automatically detects known vulnerabilities based on a database of public security issues. A pentest goes further: a human ethical hacker actively investigates how vulnerabilities can be combined into an attack path, just as a real attacker would. A scan tells you what is wrong; a pentest shows you what is possible.

This distinction is crucial when assessing a new release. Suppose an update introduces a new API integration with an incorrect permission configuration. A vulnerability scanner may not flag that configuration as critical, because the finding scores low in isolation. A human pentester, however, sees how that misconfiguration can be combined with an existing weakness elsewhere in the system, together leading to full access to sensitive data.

Attackers think in attack paths, not in isolated findings. That is precisely why an automated scan after a release is useful as a first check on basic hygiene, but a manual pentest is necessary to understand what an attacker can truly achieve. Read more about this difference on the page about cyber research.

How do you structurally embed pentesting into your release process?

Structurally embedding pentesting into a release process means determining in advance which types of changes require which level of testing, and recording those agreements in your development cycle. The goal is that security is not an afterthought following a release, but a fixed step in the process itself.

A practical approach works with three levels:

1. Automated scans with every release: Integrate vulnerability scanning into your CI/CD pipeline so that known vulnerabilities are automatically detected before production.
2. Delta pentests for significant changes: Establish clear criteria for which changes require a targeted test. Document the scope per release and have an ethical hacker assess the new components.
3. Full pentests at fixed intervals: Schedule a full penetration test at least once or twice a year, regardless of release frequency. This catches blind spots that fall outside the scope of delta tests.

Organisations with a high release frequency benefit from a model in which pentests are scheduled as part of sprint planning or the release calendar, not as a separate activity afterwards. This prevents security from always lagging behind.

An additional benefit of this approach is that teams build security awareness as a natural part of the development process. Developers who know their code will be tested think differently about the choices they make while building.

How Q-Cyber helps with pentesting after a software release

At Q-Cyber, we understand that a software release is not the endpoint of your security effort, but a new starting point. We help organisations structure and implement pentesting effectively, tailored to their release cadence and risk level. What we offer:

• Manual pentests carried out by certified ethical hackers, focused on attack paths rather than isolated findings
• Delta pentests for targeted assessment of new or modified functionality after a release
• Continuous-Q®: an ongoing testing programme for organisations that want continuous insight into their actual vulnerabilities, not just once a year
• Independent advice on how to structurally embed security into your development process, without dependency on software vendors
• Clear reports with concrete priorities, so that after every test you immediately know where action is required

Want to know whether your organisation needs to be retested after a recent release, or how to structurally set up pentesting? Get in touch with us and we will be happy to think along with you.

Lees meer

Why a CVSS Score Doesn’t Always Tell You How Much Risk You Actually Face

Geplaatst op: 14 October 2026

When a security scanner reports a vulnerability with a CVSS score of 9.8, alarm bells start ringing at many organizations. Understandable, as such a high score suggests a critical risk. But does a score of 9.8 automatically mean your organization is in great danger? Not necessarily. The CVSS score tells you something about the severity of a vulnerability in general, but says little about the actual risk you face in your specific situation.

In this article, we explain step by step what a CVSS score exactly is, how it is calculated, and why it is only one piece of a much larger puzzle. We build from the basic principles to practical tools for prioritizing vulnerabilities based on actual risk, not just a number.

What is a CVSS score and how is it calculated?

CVSS stands for Common Vulnerability Scoring System and is a standardized method for assessing the severity of a security vulnerability. The system assigns scores from 0.0 to 10.0, with a higher score indicating a more severe vulnerability. CVSS is used worldwide by security teams, software vendors, and auditors as a common language for risk assessment.

The score is calculated based on a series of metrics, divided into three groups:

• Base Score: The inherent properties of the vulnerability itself, such as how easy it is to exploit, whether authentication is required, and what impact a successful attack has on confidentiality, integrity, and availability.
• Temporal Score: Factors that change over time, such as whether a public exploit is already available and whether a patch exists.
• Environmental Score: Adjustments based on the specific environment of an organization, such as how critical the affected system is within your infrastructure.

In practice, the Environmental Score is rarely fully completed. Most tools only report the Base Score, which is immediately one of the biggest sources of misinterpretation in vulnerability management.

How the CVSS score ignores the context of your environment

The Base Score describes a vulnerability as if it exists in a vacuum, detached from any specific environment. That is useful for comparison, but dangerous if you use the score directly as a prioritization basis for your organization.

Consider this: a vulnerability has a CVSS score of 9.8 because it is remotely exploitable without authentication. But if the affected system sits behind a firewall that fully blocks external access, the chance that an attacker actually reaches this system is minimal. The score does not change, but your risk does.

The reverse also applies. A vulnerability with a score of 4.0, which looks “medium” on paper, can be catastrophic in your environment if the affected system has access to sensitive customer data or drives critical business processes. The CVSS score does not account for this, unless you carefully complete the Environmental Score — something that rarely happens structurally in day-to-day practice.

During a thorough pentest, an ethical hacker does not only look at individual scores, but specifically at how a vulnerability fits within the broader context of your systems and processes.

Exploitability and threat context as missing puzzle pieces

Two factors that the CVSS score structurally underrepresents are real-world exploitability and threat context. Together, they largely determine how urgent a vulnerability truly is.

Real-world exploitability

Not every vulnerability with a high CVSS score is also actively being attacked. Some vulnerabilities are technically complex to exploit and require specific access or circumstances that rarely occur. Others already have ready-made exploit tools available that even inexperienced attackers can deploy. This difference is enormously relevant for prioritization, but the Base Score does not make this distinction.

Threat context

Threat context is about the question: who wants to attack you, and for what purpose? A vulnerability in industrial control systems is particularly relevant if you are an energy company, but barely relevant if you run an online store. Threat actors target specific sectors, technologies, and organization types. A risk assessment that does not account for who would want to attack you and why is missing a crucial piece of the picture.

Building on what we established earlier: the CVSS score describes the vulnerability, but not the attacker. Attackers do not think in scores. They think in attack paths: which combination of weaknesses will get them to their goal? That is a fundamentally different perspective from a list sorted by CVSS score.

How do you prioritize vulnerabilities based on actual risk?

Effective risk assessment requires more than a single number. A workable prioritization framework combines the CVSS score with additional factors that determine the actual impact in your environment.

Consider the following questions for each vulnerability:

1. Is the system reachable by an attacker? A vulnerability on an internal system without external access is harder to exploit than a vulnerability on a publicly accessible web server.
2. How critical is the affected system? Systems that process customer data, handle payments, or drive critical processes deserve higher priority than test environments.
3. Is there an active exploit available? If public exploit code exists, the barrier for attackers is much lower. This significantly increases urgency.
4. Is the vulnerability part of an attack path? A vulnerability with a low score can become dangerous if, combined with other weaknesses, it leads to full access to critical systems.
5. Is there a patch or workaround available? If a fix exists, the priority to apply it quickly is higher than when you depend on a vendor.

This kind of context-driven analysis aligns with what is known in the security world as risk-based vulnerability management: not patching in order of CVSS score, but based on actual risk to your organization.

Common mistakes when interpreting CVSS scores

Even experienced security teams regularly make the same mistakes when working with CVSS scores. By knowing them, you can avoid them.

Mistake 1: Treating the Base Score as the definitive risk

The most common mistake is using the Base Score as the sole measure for prioritization. As discussed earlier, the Base Score completely ignores your specific environment. A score of 9.8 on a system that no one can reach is less urgent than a score of 5.0 on a publicly accessible system with sensitive data.

Mistake 2: Only looking at individual vulnerabilities

Attackers do not see isolated findings. They see attack paths. An incorrect Azure configuration, overly broad permissions, and an unsecured application setting may each be scored low on their own. But combined, they can lead to full access to cloud resources. Those who only look at individual CVSS scores completely miss this combined threat.

Mistake 3: Wanting to patch everything at once

Organizations that want to immediately fix every vulnerability with a high CVSS score quickly become overwhelmed. Without prioritization based on actual risk, security teams get consumed by urgency that exists on paper but is limited in practice. The result is that the truly dangerous vulnerabilities are sometimes addressed too late.

Mistake 4: Ignoring the Temporal and Environmental Score

Many tools display only the Base Score by default. The Temporal Score and Environmental Score exist precisely to refine the score to your situation. Completing the Environmental Score takes time, but delivers a considerably more realistic picture of your actual risk.

From CVSS score to a continuous risk picture

Building on everything covered above: a CVSS score is a starting point, not an endpoint. Those who base their vulnerability management on an annual scan and a sorted list of scores have insight at that one moment, but do not know what changes afterward.

IT environments are constantly in motion. Applications are updated, accounts added, permissions changed, and new cloud resources created. Every change can introduce new vulnerabilities or place existing vulnerabilities in a different light. A vulnerability that had low priority last month can suddenly become part of a dangerous attack path due to a configuration change.

Effective vulnerability management therefore requires a continuous risk picture: regular revision of priorities, combined with insight into how your environment changes and which new threats become relevant. That is fundamentally different from an annual snapshot.

Moreover, a continuous risk picture requires the ability to recognize attack paths, not just individual vulnerabilities. That demands the mindset of an attacker: who wants to target me, how would they go about it, and which combination of weaknesses would they exploit? Automated scanners do not answer that question. Human reasoning does.

How Q-Cyber helps with risk assessment beyond the CVSS score

At Q-Cyber, we believe that a CVSS score only gains meaning when it is placed in the context of your organization, your environment, and the threats that are relevant to you. We help organizations move from a list of vulnerabilities to a realistic and actionable risk picture.

Concretely, we do this through:

• Manual pentests in which our ethical hackers not only identify individual vulnerabilities, but also investigate how those vulnerabilities can be combined into attack paths that are truly dangerous.
• Attack path analysis that makes clear which combinations of weaknesses, misconfigurations, and permissions pave the way for an attacker to critical systems, even when individual findings score low.
• Context-driven prioritization so your security team knows which vulnerabilities are truly urgent in your specific environment, instead of working based on a generic score.
• Continuous insight through our Continuous-Q® program, so you are not dependent on an annual snapshot but maintain an up-to-date risk picture that moves with your environment.

Want to know how your organization truly stands, beyond the CVSS scores? Get in touch with us and we will look together at what your situation requires.

Lees meer

What Is Permission Creep and Why Is It Dangerous?

Geplaatst op: 13 October 2026

Every employee who needs access to something gets that access. That sounds logical and even friendly. But in practice, this pattern is one of the most underestimated security risks within organizations. Access rights are granted, but rarely if ever revoked. The result: a slow but steady accumulation of permissions that no one oversees anymore, and that attackers are all too happy to exploit.

In this article, you’ll learn step by step what permission creep is, how it arises, why it’s so dangerous, and what you can concretely do about it. We start with the basics and build from there toward practical application.

What is permission creep and how does it arise?

Permission creep is the gradual process by which users, systems, or applications accumulate more access rights than they actually need for their work. The word “creep” is deliberately chosen: it’s not about a sudden mistake, but about a stealthy process that develops over months or years.

The cause is almost always operational convenience. An employee temporarily needs access to a system for a project. That access is granted, but never reversed once the project is completed. That same employee later moves to a different role, for which new permissions are added. The old permissions simply remain. After a few years, that person has access to systems and data that have nothing to do with their current role.

Think of a new colleague who temporarily gets access to the financial administration to cover for a colleague. After that period, the access is not revoked. Six months later, that same person works in a different department, but still has full read access to sensitive financial data. That is permission creep in practice.

How permission creep spreads through an organization

Permission creep starts with one user, but spreads quickly when there is no active management in place. Especially in larger organizations, where dozens or hundreds of employees regularly change roles, it is nearly impossible to manually track who has access to what.

There are three common patterns through which permission creep spreads:

• Role changes without a permissions review: with internal promotions or role changes, new permissions are added but old ones are not removed.
• Shared accounts and service accounts: technical accounts are given broad permissions for convenience but are never cleaned up.
• Onboarding templates that are too broad: new employees are given more access than necessary by default, because it’s easier to restrict later than to keep requesting access repeatedly.

In cloud environments such as Microsoft Azure or Microsoft 365, this process accelerates even further. Permissions are easily granted here via RBAC roles (Role-Based Access Control), but oversight is often lacking. A misconfiguration in Azure permissions can, in combination with other weaknesses, lead to access to critical cloud resources. Read more about how such weaknesses converge in our research on attack paths.

Why permission creep poses a serious security risk

Permission creep is dangerous because it expands an organization’s attack surface without anyone consciously deciding to do so. Every unnecessary access right is a potential entry point for an attacker, a malicious insider, or a compromised account.

What makes this risk particularly serious is that individual access rights may seem harmless on their own. But attackers don’t think in isolated findings. They look for attack paths: combinations of small weaknesses that together lead to significant damage. An overly broad permission combined with a misconfiguration and a weak password may be enough to gain full access to a system.

Moreover, compromised accounts with excessive permissions are particularly valuable to attackers. They can move laterally through a network, escalate privileges, and remain undetected for a long time. A thorough penetration test shows exactly what such attack paths look like in your specific environment.

The principle of least privilege as a counterweight

The answer to permission creep is the principle of least privilege: every user, application, or system is granted only the minimum access rights needed to perform a specific task, and nothing more.

Least privilege is not a technical setting you switch on once. It is a design principle that must be consistently applied with every assignment of permissions. That means:

• Access is granted based on role and task, not based on convenience.
• Temporary access has an expiration date.
• Administrator rights are only granted when truly necessary, and not as a default setting.

A good example is the use of Just-in-Time (JIT) access: an administrator receives elevated permissions only for the duration of a specific task, after which those permissions are automatically revoked. This significantly reduces the risk window. Least privilege is therefore the direct counterweight to the stealthy accumulation that permission creep causes.

Common mistakes in managing access rights

Building on the least privilege principle, it’s useful to understand where things most often go wrong in practice. Because even organizations that know the principle regularly make the same mistakes.

The most common pitfalls are:

• No offboarding process for permissions: when an employee leaves, accounts are sometimes not disabled or disabled too late.
• No periodic access review: permissions are configured once and never checked again.
• Overly broad default roles: using global administrator roles where specific roles would suffice.
• No distinction between production and test environments: the same broad permissions apply in both environments, while test environments are often less well secured.
• Relying on users to self-report permissions: employees rarely indicate that they no longer need access to something.

A common misconception is that identity security is only relevant for large organizations. In reality, permission creep affects organizations of every size, precisely because it is a consequence of ordinary business processes and not of deliberate negligence.

How to structurally address permission creep

Now that the causes and risks are clear, the question is: how do you concretely tackle permission creep? A structural approach requires more than a one-time cleanup. It calls for processes that actively manage permissions throughout the entire lifecycle of a user or system.

An effective approach consists of the following steps:

1. Inventory who has access to what: start with a complete overview of all accounts, roles, and permissions in your environment. Without this overview, targeted action is not possible.
2. Conduct periodic access reviews: schedule at least twice a year a review in which managers confirm which permissions their team members still need.
3. Automate the revocation of temporary permissions: use tools that automatically terminate temporary access after a set period.
4. Link permissions to roles, not to individuals: ensure that access rights are managed via job profiles, so that a role change automatically leads to the correct permissions administration.
5. Test whether permissions work in practice as intended: granting is one thing, but verifying that permissions are effectively restricted is a step that many organizations skip.

That last point is crucial. Technical configurations may look correct on paper, but in practice, combinations of settings can create unexpected access possibilities. A solid policy framework lays the foundation, but without technical validation you don’t know whether that policy actually works.

How Q-Cyber helps address permission creep

Permission creep is rarely visible until it’s too late. Q-Cyber helps organizations discover this stealthy risk and address it structurally, before an attacker can exploit it.

What we offer in this regard:

• Pentests focused on identity and permissions: our ethical hackers investigate not only known vulnerabilities, but also how overly broad permissions and misconfigurations can be combined into a working attack path.
• Attack path analysis: we map out how individual weaknesses in your environment can together lead to serious damage, including privilege escalation via permission creep.
• Advice on least privilege and access management: we help develop policies and set up processes that structurally prevent permission creep.
• Continuous-Q® for ongoing insight: through our Continuous-Q program we continuously monitor your environment, so that new permissions or configuration changes are immediately assessed for risk.

Want to know how your organization is doing? Get in touch with us and we’ll look together at the first step.

Lees meer

Why Doesn’t a Hacker Always Start With a Technical Exploit?

Geplaatst op: 12 October 2026

A hacker in a hoodie sitting behind a screen for hours typing lines of code: it’s an image many people have in mind when they think of a cyberattack. But the reality is different. Many attacks don’t start with a technical exploit, a zero-day, or a sophisticated piece of malware at all. They start with a conversation, an email, or even a friendly phone call. Understanding how cybercriminals really operate is the first step toward a better defense.

In this article, you’ll learn step by step how attackers exploit the human factor, which techniques they use to do so, and how your organization can grow from awareness to real resilience. We build the knowledge from the foundation to practice, so that by the end you not only understand what social engineering is, but also how to recognize and counter it.

What is social engineering and how does it work?

Social engineering is the art of manipulating people into revealing confidential information or performing actions that benefit the attacker. Instead of attacking a technical system, the cybercriminal targets the person operating that system.

The technique works because people are naturally trusting, helpful, and responsive to pressure or authority. An attacker exploits those traits by creating situations in which the victim believes they are acting logically and correctly, while in reality they are opening the door to a cyberattack. Social engineering is therefore not a technical problem: it is a human problem with technical consequences.

A simple example: someone calls the office and introduces themselves as an IT helpdesk employee. They ask to quickly reset a password because there is an urgent problem. Without suspicion, the employee on the phone provides the requested information. The attacker is in, without writing a single line of code.

Why people are both the weakest and strongest point in security

Technical security measures such as firewalls, encryption, and antivirus software are valuable, but they only protect systems. They do not protect the decisions people make. That makes the human factor simultaneously the most vulnerable and the most valuable element in any security strategy.

Vulnerable, because a well-trained attacker is capable of manipulating virtually anyone when the circumstances are right. Stress, time pressure, trust in authority, and the desire to be helpful are universal traits that don’t disappear by installing better software.

But people are also the strongest point. An employee who recognizes a suspicious request and reports it can stop an attack before anything even goes technically wrong. Organizations that invest in awareness and training are effectively building a human detection system that is continuously active. That is something no technical system can fully replace.

Common non-technical attack techniques explained

Cybercriminals have a broad arsenal of non-technical techniques. It is important to know these so you can recognize them when they are deployed.

Phishing

Phishing is the most common form of social engineering. The attacker sends an email that appears to come from a trusted source, such as a bank, a colleague, or a government agency. The goal is to lure the recipient into clicking a link, opening an attachment, or entering login credentials on a fake website.

Pretexting

With pretexting, the attacker invents a credible story — a so-called pretext — to gain trust. Think of someone posing as a new supplier, an auditor, or a colleague from another department. The story is carefully constructed and sounds plausible, so the victim does not question the intentions of the caller or writer.

Baiting and quid pro quo

Baiting plays on curiosity or greed. A classic example is a USB drive “accidentally” left in a parking lot or office. Anyone who plugs the drive into a computer unknowingly installs malware. Quid pro quo works in a similar way: the attacker offers something, such as free technical assistance, in exchange for access or information.

Vishing

Vishing is phishing over the phone. The attacker calls and poses as an employee of a bank, a government agency, or an internal IT department. Over the phone it is harder to verify an identity, which makes this technique particularly effective.

How an attack unfolds in practice: from first contact to breach

A social engineering attack is rarely impulsive. Attackers work methodically and take the time to study their target. The process typically follows a number of recognizable phases.

1. Reconnaissance: The attacker gathers information about the target via LinkedIn, the company website, social media, and public sources. They learn who the employees are, which systems are used, and how the organization is structured.
2. Building trust: With that information, the attacker constructs a credible story. They know the names of colleagues, are familiar with internal processes, and speak the language of the organization. This makes their approach difficult to distinguish from a legitimate request.
3. Execution: The attacker makes contact via email, phone, or even in person. They steer the victim toward an action: opening a link, passing on a password, or making a payment.
4. Access and escalation: Once the attacker has an initial foothold, they use it to move further into the network. What began as a human error grows into a full-blown breach of systems.

This pattern shows why technical security alone is not sufficient. The attacker bypasses the technical layer by entering through the human layer.

Recognize the signs before it’s too late

Many social engineering attacks are recognizable if you know what to look for. It’s not about paranoia, but about healthy alertness. Build on what you’ve just learned about the techniques attackers use and translate that into concrete signals in practice.

Watch out for the following warning signs:

• Urgency or pressure: messages that emphasize you must act now, without time for verification
• Unusual requests: requests for passwords, payments, or access that fall outside normal procedure
• Suspicious senders: email addresses that are almost correct but differ by just a letter or domain
• Too good to be true: offers, prizes, or benefits that make no sense
• Requests via unusual channels: a colleague asking via WhatsApp to do something that would normally go through email or a system

The golden principle: if in doubt, always verify through a different channel. Call the person back on a known number rather than the number listed in the message.

From awareness to resilience: what organizations can do

Awareness is the first step, but it is not enough. Resilience means that an organization not only knows that social engineering exists, but is also structurally equipped to withstand it. That requires a combination of people, processes, and technology.

Concrete steps organizations can take:

• Regular training: Ensure that employees at all levels are periodically trained in recognizing social engineering and phishing. One-time training is not enough, because attack techniques continuously evolve.
• Phishing simulations: Test employees with simulated phishing attacks to measure how alert they are and where additional attention is needed.
• Clear reporting procedures: Make sure everyone knows what to do when they receive a suspicious message. A low-threshold reporting procedure increases the likelihood that attacks are detected early.
• Policies and procedures: Establish how employees handle sensitive information, payment requests, and external contacts. Clear guidelines and policies reduce the room for manipulation.
• Technical layers as a safety net: Use multi-factor authentication, email filters, and access controls as technical safety net measures alongside the people-focused approach.

Resilience is not an endpoint. Attackers adapt their techniques and an organization must adapt along with them. That requires a culture in which security is a shared responsibility, not something that rests solely with the IT department.

How Q-Cyber helps strengthen your human line of defense

Knowing that social engineering exists is one thing. Knowing how vulnerable your own organization is to it right now is another. We help organizations gain that insight and grow from awareness to real resilience.

What we do for that:

• Phishing simulations: We test how employees respond to simulated phishing attacks and provide insight into where the vulnerabilities lie.
• Pentests: Through a thorough pentest, we map out how an attacker — both technically and via the human factor — could infiltrate your organization.
• Security awareness training: We deliver training that not only informs employees but also drives behavioral change.
• Policy advice: We assist with drafting clear procedures and guidelines that reduce the room for manipulation.
• Continuous insight via Continuous-Q®: Through our Continuous-Q® program, we monitor your security throughout the entire year, not just on the day of a test.

Want to know how vulnerable your organization is to social engineering and other attack techniques? Contact us and we’ll look together at the best approach for your situation.

Lees meer

Why Is One Pentest Per Year Not Always Enough?

Geplaatst op: 11 October 2026

A pentest is on the annual agenda of many organisations. It feels familiar, it produces a report, and the box is ticked. But is the picture that you are therefore secure actually accurate? In this article we explain step by step what a penetration test truly measures, where the limits of an annual approach lie, and how to align your testing frequency with the actual risks of your organisation. We build from basic concepts towards concrete choices you can apply immediately.

What does a pentest actually do, and what doesn’t it do?

A penetration test is an authorised, simulated attack on your systems, networks, or applications. Certified ethical hackers attempt, using the same methods as real attackers, to find vulnerabilities before malicious parties do. The result is a report with concrete findings and priorities.

What many people do not know, however, is that a pentest works in layers. There are roughly three levels to distinguish:

• Layer 1: Known vulnerabilities – Think of known CVEs, public exploits, and checking whether patches have been applied correctly. This is the most visible layer.
• Layer 2: Individual weaknesses – Incorrect cloud configurations, overly broad permissions, identity weaknesses, and insecure application settings that do not appear directly in a CVE database.
• Layer 3: Correlated attack paths – This is where a good offensive security partner adds real value. Not every individual finding needs to be critical, but multiple small weaknesses can together lead to full access to your cloud resources.

A concrete example makes this clear: an SSRF vulnerability may seem limited on its own. But combine it with a managed identity, overly broad Azure RBAC permissions, and access to a Key Vault, and suddenly you have an attack path to subscription owner rights. Attackers do not see individual findings — they see attack paths. A pentest that only covers the first two layers misses the most dangerous part.

Why a pentest is a photograph of a moving target

An annual pentest provides an accurate picture of your security, but only at the moment of testing. To put it vividly, it is a photograph of a moving target.

Cybercriminals develop new attack techniques 365 days a year. New vulnerabilities are discovered daily, software configurations change with every update, and an organisation’s IT environment grows and evolves continuously. A pentest that gives the all-clear today says little about the situation three months from now.

Moreover: the more time there is between two pentests, the greater the chance that a vulnerability goes unnoticed while attackers are already exploiting it. An annual measurement therefore creates a false sense of security — not because the test is poor, but because the world around it does not stand still.

When is an annual pentest sufficient?

It is fair to acknowledge that an annual pentest is a good choice in some situations. Not every organisation has the same risk profile, and the testing frequency must always be proportional to the actual threat.

An annual penetration test may be sufficient when:

• The IT environment is relatively stable and undergoes few changes
• There is little sensitive customer data or critical business processes online
• Compliance requirements prescribe an annual test and there are no additional risks
• The organisation has additional security layers, such as continuous monitoring and vulnerability scanning

The pitfall is that many organisations view the annual pentest as the endpoint of their security effort, whereas in reality it is just one measurement within a broader security strategy. A vulnerability scan between two pentests can help bridge the intervening period.

How continuous testing closes the security cycle

Where an annual pentest offers a snapshot, continuous testing closes the security cycle. The idea is simple: you cannot defend what you do not test, and testing must therefore take place continuously, not once for a certificate or because an auditor is coming.

Continuous testing does not serve as a replacement for the in-depth pentest, but as a complement to it. It combines regular automated scans with periodic manual tests, so that new vulnerabilities are quickly discovered and the security status remains current. This closely aligns with the thinking behind Continuous-Q, where testing is not a one-off exercise but a living capability within the organisation.

If you build on this principle, the role of security shifts from reactive to proactive. Instead of waiting for the annual report, you have continuous visibility into your attack surface. That is not a luxury for large organisations — it is the logical response to a threat landscape that also does not change just once a year.

What determines the right testing frequency for your organisation

The right testing frequency is not a universal formula. It depends on a combination of factors that differs per organisation. If you base this decision on the concepts from the previous sections — the layers of a pentest, the dynamics of the threat landscape, and the value of continuity — the following questions are guiding:

• How dynamic is your IT environment? Regular releases, cloud migrations, and new integrations expand the attack surface and call for more frequent testing.
• How sensitive is your data? Organisations that work with personal data, financial information, or critical infrastructure require a higher testing frequency.
• Do you serve other organisations? Managed Service Providers are a favourite target of cybercriminals, precisely because compromising one MSP gives direct access to all of that MSP’s clients. The responsibility is greater, and the testing frequency must move accordingly.
• What compliance requirements apply? Regulations such as NIS2 impose requirements on demonstrable security efforts. A compliance framework can serve as a minimum baseline, not as an endpoint.
• How quickly do you want to respond to new threats? Organisations with a low risk tolerance opt for shorter testing cycles and additional red team exercises to also simulate advanced attack scenarios.

The core of all this is that the testing frequency must be a deliberate choice, based on your actual risk profile — not on habit or convenience. An annual pentest is a good starting point, but rarely the endpoint of a mature security strategy.

How Q-Cyber helps with continuous pentesting

At Q-Cyber we believe that security is not a snapshot, but an ongoing process. We help organisations take the step from an annual pentest to a security strategy that moves with the threat landscape. Concretely, we do this in the following ways:

• In-depth pentests that not only report individual vulnerabilities, but also expose correlated attack paths that automated tools miss
• Continuous-Q, our continuous testing programme developed specifically for organisations that want ongoing visibility into their attack surface
• Independent advice on the right testing frequency for your organisation, without dependency on software vendors or other suppliers
• Red team exercises for organisations that also want to simulate advanced attack scenarios
• Compliance guidance for organisations that need to comply with NIS2 or other regulations

Want to know whether your current testing frequency matches your actual risk profile? Get in touch and we will be happy to think along with you.

Lees meer

Why Don’t Hackers Always Use the Most Advanced Attack Technique?

Geplaatst op: 30 September 2026

When people think of hackers, they often picture a figure working with complex exploits, self-written malware, and advanced technical tricks. The reality is far more straightforward. Most successful cyberattacks don’t begin with a technical masterpiece, but with a simple choice: what is the easiest way in? This article explains step by step how cybercriminals think when choosing their approach, why simple methods are so effective, and what this means for the security of your organisation.

By understanding how attackers reason, it becomes clear why technical defence alone is never enough. The insights in this article build on one another: from the motivation behind an attack, to the techniques used, to the role of people, and ultimately to what your organisation can do about it.

What drives a hacker when choosing an attack technique?

An attacker chooses a technique based on one central question: what costs me the least effort for the greatest result? This sounds simple, but it explains a lot. Cybercriminals are not romantic figures who seek out a challenge. Most are rational actors who weigh up time, risk, and reward.

Before an attacker executes a single exploit, they conduct reconnaissance. They investigate how an organisation is structured, which suppliers have access, which accounts exist, and what rights those accounts have. Much of this information is publicly available via LinkedIn, job postings, domain names, and technical metadata. An attacker can already learn a great deal about where an organisation is vulnerable, even before launching a technical attack.

The choice of attack technique then follows logically. If a phishing email is sufficient to gain access, there is no reason to spend weeks developing a sophisticated exploit. Advanced techniques are deployed when simple methods don’t work, not the other way around.

How simple techniques work in practice

The most commonly used attack techniques are not advanced. They are effective because they exploit something that is always present: human behaviour and basic technical problems that have never been resolved.

Phishing as a gateway

Phishing is by far the most common method by which cybercriminals gain an initial foothold. An email that looks like a message from a colleague, a supplier, or a bank asks for an action: click a link, log in, open an attachment. One employee who responds is enough. The attacker then has access to an account and can move further within the network from there.

Password reuse and weak credentials

A second widely used method is testing known password combinations. People reuse passwords across multiple platforms. If a password has been obtained elsewhere through a data breach, an attacker tries that same password on corporate systems. This is called credential stuffing and requires no technical expertise whatsoever, only a list of leaked credentials and an automated script.

Known vulnerabilities that have not been patched

Many organisations run software with known security flaws for which a patch has long been available. Attackers systematically scan the internet for such vulnerabilities. They don’t need to discover the flaw themselves: the information is publicly available in databases such as the CVE registrations. An attacker simply selects a vulnerability, finds a target that has not yet patched it, and gets to work.

Why advanced attacks are overkill for most targets

Advanced attack techniques certainly exist. Think of zero-day exploits, supply chain attacks, or combining multiple small weaknesses into a single working attack path. But these techniques require a great deal of time, knowledge, and preparation. For most attackers, that is simply not necessary.

A common misconception is that attackers are always looking for the most spectacular entry point. In reality, the principle of least resistance applies. If an organisation has not enabled multi-factor authentication, a stolen password is already sufficient. If employees have not been trained to recognise phishing, a fake email is enough. Advanced techniques only become relevant once all simple paths have been closed off.

This also means that an organisation that does not have its basic security in order is not a target for advanced attacks, but for opportunistic attacks. These are less visible, but at least as damaging. A professional pentest reveals which of these simple paths are still open.

The human factor as the weakest link

Technical security can be impressive. Firewalls, encryption, patch management, strong password policies: these are all valuable measures. But all of these measures lose their value the moment an employee clicks on a wrong link, shares a password, or carries out a request without verifying it.

Social engineering is the umbrella term for attack techniques that exploit human behaviour rather than technical vulnerabilities. An attacker poses as a colleague from the IT department and requests access. Or they call reception with a convincing story and ask for a password reset. This approach works because people are naturally inclined to help and trust, especially when a request comes across as urgent or authoritative.

What is interesting about social engineering is that no technical system can stop it entirely. The only effective defence is awareness: employees who know how attackers operate and who know when to verify a request. Cybersecurity awareness is therefore not a luxury but a basic requirement. In addition, red teaming offers a realistic way to test how an organisation responds to simulated social engineering attacks.

What this means for the security of your organisation

The core message of this article is a simple but important lesson: attackers choose the easiest path. This means that an organisation’s security is only as strong as its weakest link, not its strongest. A sophisticated firewall is no help if employees cannot recognise phishing emails. An extensive patch policy is no help if accounts do not have multi-factor authentication.

In practical terms, this means organisations need to distribute their attention across three levels:

• Address known vulnerabilities: Ensure patches are applied and known security flaws are remediated. This closes the most straightforward attack paths.
• Review configurations and access rights: Incorrect settings in cloud environments, overly broad permissions, and unmanaged accounts are favourite entry points for attackers who look slightly beyond the surface.
• Train and test employees: Awareness of phishing, social engineering, and secure behaviour is not a one-time effort but an ongoing one. Attackers adapt their methods, and employees must do the same.

Security is not a destination. An organisation is constantly changing: new applications, new employees, new cloud resources. Every change can introduce a new point of vulnerability. Those who only test their security at a fixed moment in time only know they were secure on that day.

How Q-Cyber helps you understand attack techniques

We help organisations understand how attackers truly operate, not just in theory but by actually simulating it. Our approach focuses on exposing the paths a real attacker would choose, from simple phishing attacks to complex combinations of weaknesses that together form an attack route.

What we concretely offer:

• Manual pentests in which our ethical hackers think like an attacker, including reconnaissance of organisational structures, identities, and access rights
• Phishing simulations to measure how employees respond to realistic social engineering attempts
• Continuous insight via Continuous-Q, so you know where you stand not just on the test day but throughout the entire year
• Concrete recommendations that go beyond a list of vulnerabilities, focused on the attack paths that truly matter

Want to know which simple attack paths are still open in your organisation? Contact us for a no-obligation conversation.

Lees meer

Can a pentest give a false sense of security?

Geplaatst op: 29 September 2026

Yes, a pentest can create a false sense of security, and this happens more often than organizations realize. A one-time penetration test provides insight into vulnerabilities at one specific moment, but says nothing about the state of your security a week, a month, or a quarter later. Below we discuss when a pentest falls short, what remains invisible, and when a test does prove its value.

When does a pentest give a distorted picture of your security?

A pentest gives a distorted picture when its outcome is treated as a final verdict on your security rather than as a snapshot in time. Once the report disappears into a drawer and the recommendations are not followed up, or worse: when the conclusion is “we’ve been tested, so we’re secure,” the test backfires. The false sense of security that arises is more dangerous than having no test at all.

One of the most common misconceptions is that the number of vulnerabilities found says something about how secure you are. That is not correct. An environment with ten low-severity findings can be considerably more vulnerable than an environment with three critical findings, depending on how those findings relate to each other. Attackers do not look at individual technical findings. They look for attack paths: combinations of small weaknesses that together lead to full access.

A concrete example: an SSRF vulnerability may seem manageable on its own. But when combined with a managed identity, overly permissive Azure RBAC rights, and access to a Key Vault, the result can be that an attacker becomes subscription owner. None of those findings is critical on its own. Together they form a complete attack path to your cloud infrastructure. A pentest that only looks at individual findings completely misses these kinds of combined attack chains.

What are the limitations of an annual pentest?

The biggest limitation of an annual pentest is that the security landscape is constantly changing, but the test is not. An annual penetration test is essentially a photograph of a moving target: the image is accurate at the moment of the test, but everything that changes afterward remains out of frame. Cybercriminals develop new attack techniques 365 days a year, and an annual test only notices that when it is already too late.

Concretely, this means that the following things fall outside the view of an annual pentest:

• New vulnerabilities (CVEs) published after the test date
• Configuration changes in cloud or network infrastructure that introduce new risks
• New applications, integrations, or connections put into use after the test
• Changed access rights or identity settings that make permissions too broad
• New attack techniques not yet included in standard testing methodologies

On top of that, an annual pentest is often performed because an auditor or certification requires it, not out of a genuine security need. That motivation influences the scope, depth, and follow-up of the test. The result is a report that demonstrates compliance but does not give a realistic picture of the organization’s actual resilience.

How does a one-time pentest differ from continuous security testing?

A one-time pentest is a snapshot: a structured attack on a defined system or network, carried out at a single point in time. Continuous security testing is an ongoing process in which vulnerabilities, configurations, and attack paths are systematically monitored and assessed. The difference lies not only in frequency, but also in how findings are followed up and how quickly new risks are identified.

With a one-time penetration test, the tester’s involvement ends when the report is delivered. With continuous security, the testing capability remains active: new vulnerabilities are identified immediately, changes in the environment are taken into account, and the security status is continuously measured. That is a fundamentally different approach to cybersecurity, where security is treated not as a project but as a living capability.

For organizations that bear responsibility for the security of others, such as Managed Service Providers, this distinction is particularly relevant. An MSP that is tested once a year effectively also offers its clients certainty only once a year. Continuous security testing aligns with the reality that attackers do not wait for the next test cycle.

What risks remain invisible after a standard pentest?

After a standard pentest, the risks that remain invisible are particularly those arising from the combination of multiple small weaknesses, from changes after the test date, or from attack techniques that fall outside the agreed scope. A standard penetration test typically looks at known vulnerabilities and direct exploitation opportunities, but misses the deeper layers of an attack surface.

There are three levels at which vulnerabilities exist:

1. Known vulnerabilities (Layer 1): Public CVEs, uninstalled patches, and known exploits. This is the layer that most standard pentests and vulnerability scans cover.
2. Individual weaknesses (Layer 2): Misconfigured cloud settings, overly permissive permissions, identity weaknesses, and insecure application settings. These are less consistently addressed, but are often the entry point for attackers.
3. Correlated attack paths (Layer 3): The combination of multiple small findings that together lead to a complete attack path. This is the layer that most standard pentests structurally miss, and precisely the layer attackers focus on.

Attackers do not see isolated findings. They see paths. A red team approach that examines how weaknesses relate to each other reveals risks that a standard penetration test would never uncover. That is the difference between knowing a window is open and understanding that the window looks out onto the server room.

When is a pentest genuinely valuable as part of your security strategy?

A pentest is valuable when it is used as part of a broader security strategy, not as a replacement for one. A penetration test has real value as a starting point for structural improvement, as a measurement of specific systems or applications, and as a complement to continuous security measures. The test itself is not the problem; the way organizations handle it is.

Concrete situations in which a pentest does prove its value:

• At the launch of a new application or service, before it goes into production
• After a major infrastructure change, such as a cloud migration or network expansion
• As a baseline measurement at the start of a cybersecurity improvement program
• As part of a due diligence process during mergers or acquisitions
• As a complement to an ongoing security program, to provide depth on specific components

The key is that the findings are actually acted upon and that the test is not seen as an endpoint. A pentest that leads to concrete improvements, and is subsequently followed by monitoring and retesting, contributes to genuine resilience. A pentest that ends in a report contributes to a false sense of security.

How Q-Cyber helps prevent false security

At Q-Cyber, we never treat a pentest as a standalone product. We help organizations make the step from a one-time snapshot to structural, demonstrable resilience. We do this in a number of concrete ways:

• In-depth pentests with a focus on attack paths: Our ethical hackers look not only at individual vulnerabilities, but investigate how findings relate to each other and what attack chains arise as a result.
• Continuous-Q® for ongoing security: For organizations that want to test on a structural basis, we offer a program in which security is continuously measured and adjusted, not just once a year.
• Red team testing: With a simulated attacker on our team, we can replicate attacks the way real cybercriminals carry them out, including techniques that fall outside standard testing methodologies.
• Independent advice: We are not tied to software vendors or suppliers. Our recommendations are based purely on what works for your organization.

Want to know whether your current security provides genuine resilience or a false sense of security? Get in touch with Q-Cyber and we will discuss together what the right approach is for your situation.

Lees meer

When Is a CVE Actually Exploitable?

Geplaatst op: 28 September 2026

A CVE is truly exploitable when a working exploit exists, the attacker has access to the vulnerable system, and the configuration of your environment makes the attack path possible. Not every published vulnerability automatically poses a danger. Whether a CVE affects your organization depends on the combination of available exploits, environmental factors, and the likelihood that an attacker takes that specific route. Below we answer the most frequently asked questions about CVE exploitability and vulnerability management.

What determines whether a CVE is genuinely dangerous?

A CVE is dangerous when three elements converge: a working exploit is available, the vulnerable system is reachable by an attacker, and the vulnerability fits within a realistic attack path. If one of these elements is missing, the actual risk drops significantly, even if the theoretical severity of the CVE is high.

Many organizations are overwhelmed by the enormous number of CVEs published each year. In 2026, dozens of new vulnerabilities are documented every day. But the vast majority of them are never actively exploited, simply because attackers choose the path of least resistance. They look for combinations of weaknesses that together form a working attack path, not the most complex exploit.

Exploitability is therefore not a binary property of a CVE itself. It is a property of the interaction between that vulnerability and your specific environment. That is what makes contextual vulnerability research so valuable: only when you understand how an attacker would approach your systems do you know which CVEs are truly dangerous.

What does a CVSS score tell you — and what doesn’t it tell you — about exploitability?

A CVSS score indicates how severe a vulnerability theoretically is, based on factors such as attack vector, complexity, and impact. What the score does not tell you is whether the vulnerability is being actively exploited, whether a working exploit is available, or whether your specific configuration is vulnerable.

The CVSS score is a useful starting point for prioritization, but dangerous as the sole metric. A CVE with a score of 9.8 in software you don’t use is less urgent than a CVE with a score of 6.5 in a system that is directly reachable from the internet. Yet many organizations see a high CVSS score and react as if the impact is automatically significant.

What exactly does CVSS measure?

CVSS looks at the attack vector (network, local, physical), the required complexity of the attack, the privileges needed, and the potential impact on confidentiality, integrity, and availability. These factors are combined into a score between 0 and 10.

What does CVSS miss?

CVSS does not account for the availability of public exploits, active exploitation in the wild, the specific configuration of your environment, or the position of the vulnerability within a broader attack path. These are precisely the factors that determine whether a CVE is actually exploitable for you.

How do you know whether an exploit is being actively exploited in the wild?

You can tell whether an exploit is being actively exploited by consulting threat intelligence sources, such as the CISA Known Exploited Vulnerabilities (KEV) catalog, threat intelligence feeds, and vendor security bulletins. If a CVE appears on the KEV list, proven exploitation is the reason and immediate action is required.

In addition to the KEV list, there are other signals that indicate active exploitation. Security researchers regularly publish proof-of-concept exploits on platforms such as GitHub. Once such an exploit is publicly available, the likelihood of abuse increases significantly, because even less technically skilled attackers can make use of it.

Threat intelligence feeds from vendors such as Recorded Future, Mandiant, or open sources such as NVD and Exploit-DB provide insight into which vulnerabilities are actively being used in attack campaigns. Combining these sources with your own knowledge of your environment is the most reliable way to assess exploitability. This is also why manual pentests go further than automated scans: a human tester combines threat intelligence with knowledge of your specific environment.

Which environmental factors determine whether a CVE affects your organization?

The environmental factors that determine whether a CVE affects your organization are: whether you actually use the vulnerable software, how that software is configured, whether the system is reachable from the network or internet, what privileges an attacker would gain after exploitation, and whether compensating controls such as network segmentation or monitoring are in place.

A CVE in a web server is only relevant if you are running that web server and if it is reachable by potential attackers. If you are running the vulnerable version behind a firewall with no internet connection, the risk is fundamentally different from when that same server is publicly accessible.

Identities and privileges also play a crucial role. Some vulnerabilities require that an attacker already has access to a system or holds certain privileges. In that case, the question is not only whether the CVE is exploitable, but also how difficult it is for an attacker to obtain that initial access. Cloud configurations, permissions, and identity management are just as important as the technical vulnerability itself.

When should you patch a CVE immediately versus accept it?

Patch a CVE immediately when active exploitation has been confirmed, the vulnerability affects a reachable and critical system, and a working patch is available. Accept or defer a CVE when the vulnerable system is not reachable, no working exploit exists, or the cost of patching is disproportionate to the actual risk.

A structured approach to this decision combines three factors: the CVSS score as a baseline, the presence of active exploitation as an accelerator, and the environmental context as the determining factor. If a CVE is on the CISA KEV list and affects a reachable system in your environment, immediate action is always justified.

Accepting a CVE is a deliberate risk decision, not a deferral. Document why you decide to accept a vulnerability, what compensating controls are in place, and when you will revisit the decision. This keeps patch management a controlled process rather than a reactive firefighting exercise.

Why is an annual scan not sufficient for CVE management?

An annual scan is not sufficient for CVE management because your environment changes continuously. New software is installed, configurations are adjusted, accounts and privileges change, and new vulnerabilities are published every day. An annual scan gives you a snapshot of a single day, while attackers are active 365 days a year.

Suppose you run a scan in January and resolve all findings. In March, a critical CVE is published in software you use. In May, that CVE is being actively exploited. Without continuous visibility, you only find out at the next annual scan that you have been vulnerable — and that is precisely the period during which attackers strike.

Vulnerability management is not a project but an ongoing process. It requires monitoring for new CVEs, regular reassessments of your environment after changes, and a mechanism to respond quickly when active exploitation is detected. Continuous testing aligns with this reality: not a single snapshot of a moving target once a year, but continuous insight into what your environment looks like from an attacker’s perspective.

How Q-Cyber helps with CVE prioritization and vulnerability management

At Q-Cyber, we understand that the biggest challenge in CVE management is not finding vulnerabilities, but determining which ones actually matter. Our approach goes beyond a list of findings and focuses on the question that truly matters: which vulnerabilities form a realistic attack path in your specific environment?

• Manual pentests in which our ethical hackers think like an attacker, including combining CVEs with misconfigurations, identities, and permissions into working attack paths
• Contextual risk analysis that goes beyond CVSS scores and takes into account your environmental factors, reachability, and active exploitation
• Continuous insight through our Continuous-Q® program, so you know where you stand not only on the day of testing, but throughout the entire year
• Concrete prioritization with a clear distinction between vulnerabilities that require immediate action and vulnerabilities that are acceptable with compensating controls
• Independent advice without dependency on software vendors, so our recommendations are always in your best interest

Want to know which CVEs in your environment are truly exploitable? Get in touch and we will discuss which approach best fits your situation.

Lees meer