Can a Security Risk Exist Without a Known CVE?

Geplaatst op: 25 October 2026

Yes, a security risk can certainly exist without a known CVE. A CVE (Common Vulnerabilities and Exposures) is an officially registered vulnerability in software or hardware, but not every risk makes it into that database. Misconfigurations, weak access permissions, insecure architectural choices, and logical flaws in processes represent real attack vectors that never receive a CVE number, yet are actively exploited by attackers.

This distinction is crucial for organizations that base their security solely on CVE lists or automated scanners. That approach covers only a portion of the actual attack surface. In this article, we answer the most frequently asked questions about security risks without a known CVE, how attackers find them, and how you can detect them yourself.

What counts as a security risk when there is no CVE?

A security risk without a CVE is any weakness in a system, process, or environment that an attacker can exploit to gain access, cause damage, or steal data — even if that weakness has never been officially registered as a vulnerability. CVEs cover software flaws in known products, but an organization’s attack surface is much broader than that.

Concrete examples of security risks without a CVE include:

• Misconfigurations: cloud storage that is accidentally publicly accessible, a firewall with overly permissive rules, or an admin account without multi-factor authentication
• Overprivileged accounts: users or service accounts with more permissions than necessary, allowing an attacker to achieve a great deal immediately after a compromise
• Logical flaws in processes: a password reset flow that is too easy to bypass, or an API that makes assumptions about who is logged in
• Supply chain access: vendors or MSPs with direct access to systems, without that access being properly monitored or restricted
• Weak segmentation: a network where an attacker who compromises one system can move laterally almost unimpeded

All of these risks are real, exploitable, and dangerous — yet they never appear in a CVE database. An organization that focuses solely on CVEs has a blind spot the size of its own architecture.

How do attackers discover vulnerabilities without a CVE?

Attackers discover vulnerabilities without a CVE not by searching for known software flaws, but by understanding how an organization is structured. They start with reconnaissance: who works there, which vendors have access, which services are publicly visible, and what identities and permissions exist within the environment? Only then do they look for the weakest link in the whole.

An attacker looks for combinations of weaknesses that may seem harmless individually, but together form an attack path. For example, an account with excessive privileges, combined with a poorly configured VPN and a vendor with unrestricted access, can yield a complete attack path without a single CVE being involved.

What helps attackers here is publicly available information: LinkedIn profiles, job postings, technical documentation, certifications, and even job advertisements often reveal which systems and vendors an organization uses. A skilled attacker can learn a great deal about the environment before taking a single technical step. This is precisely why red team exercises are so valuable: they simulate this entire thought process, including the reconnaissance phase.

What is the difference between a zero-day and a vulnerability without a CVE?

A zero-day is a specific type of vulnerability: a software flaw that is still unknown to the vendor and for which no patch yet exists. A vulnerability without a CVE is a broader category: it encompasses everything that poses an attack risk but has not been registered as a software vulnerability, such as misconfigurations, architectural flaws, and weak processes. Every zero-day is temporarily a vulnerability without a CVE, but not every vulnerability without a CVE is a zero-day.

The distinction is practically relevant. A zero-day is rare, technically complex, and is often used in targeted attacks against large organizations or governments. Vulnerabilities without a CVE in the broader sense — such as an overprivileged service account or a poorly configured cloud environment — occur in virtually every organization and are exploited daily by attackers of all levels.

For most organizations, the risk of non-CVE vulnerabilities in the second category is therefore greater than the risk of zero-days. The first category is manageable with good configuration practices, access management, and regular testing. A zero-day is by definition harder to prevent, but also less likely to be an attack vector for the average organization.

Why do traditional vulnerability scans miss non-CVE risks?

Traditional vulnerability scans miss non-CVE risks because they are designed to recognize known software flaws, not to reason like an attacker. A scanner compares what it finds against a database of known CVEs and technical deviations. What is not in that database is not reported, regardless of how significant the actual risk is.

This has a number of direct consequences:

• A misconfiguration in a cloud platform is not flagged as a vulnerability if there is no associated CVE
• Logical flaws in applications — such as an authorization issue in a business process — fall outside the scope of automated tools
• Combinations of weaknesses that together form an attack path are not recognized because a scanner assesses each element separately
• Identity and permission issues, such as accounts with excessive privileges, are rarely picked up by standard scanners

The danger is not that a vulnerability scan is useless. For checking basic hygiene and quickly identifying known technical flaws, a scan certainly has value. The danger is that organizations think a clean scan report equals a secure environment. That is a misconception that attackers are happy to exploit. More background on the limitations of automated tools can be found in our cyber research overview.

How do you test for security risks without a known CVE?

To test for security risks without a known CVE, you need an approach that thinks like an attacker rather than like a scanner. That means manual testing by experienced specialists who explore the environment, construct attack paths, and identify logical weaknesses that fall outside the CVE database.

Concretely, there are three levels at which you can address this:

Manual penetration testing

In a manual pentest, ethical hackers investigate the environment the way an attacker would. They look not only at software flaws, but also at configurations, access permissions, architectural choices, and the way systems communicate with each other. This yields findings that a scanner structurally misses.

Red team exercises

Red teaming goes a step further: a team of attackers simulates a full attack campaign, including reconnaissance, social engineering, and lateral movement through the network. The goal is not a list of vulnerabilities, but demonstrating whether an attacker can actually achieve their objective. This type of test surfaces combinations of weaknesses that might remain invisible in a standard pentest.

Continuous monitoring and testing

A one-time test provides a snapshot. Because environments change constantly — accounts are added and configurations are adjusted — continuous testing is the most effective approach. The environment is regularly retested so that new risks are identified quickly before an attacker discovers them.

When is an annual pentest not enough?

An annual pentest is not enough when an organization’s IT environment changes throughout the year — which is the case for virtually every organization. New applications, cloud resources, accounts, vendor integrations, and configuration changes continuously create new attack vectors. A pentest that yields a clean result today says nothing about the situation three months from now.

Attackers also do not operate on an annual schedule. New attack techniques are developed and deployed throughout the year. A vulnerability that arises in February due to a configuration change can already be exploited in April, long before the next annual test takes place. An annual pentest is in that sense a photograph of a moving target: useful as a baseline, but insufficient as the sole security measure.

Specific situations in which an annual pentest demonstrably falls short:

• After every significant change to the IT infrastructure, such as a cloud migration or a new SaaS integration
• When new vendors or MSPs gain access to systems
• After changes to access permissions or the introduction of new accounts
• When the organization grows and new employees, systems, or locations are added
• After a security incident, even if that incident seemed minor

For organizations that want to continuously know whether their security holds up, a model of continuous penetration testing is the logical next step. This shifts the question from “were we secure on the test date?” to “are we secure today?”

How Q-Cyber helps with security risks without a known CVE

At Q-Cyber, we understand that the most dangerous risks often do not appear in a CVE database. Our approach is therefore not based on automated scanning, but on thinking and working like a real attacker. We help organizations map their full attack surface, including the risks that traditional tools structurally miss.

What we concretely do:

• Manual pentests: our ethical hackers investigate configurations, identities, permissions, and attack paths — not just known software flaws
• Red team exercises: we simulate a full attack campaign to test whether an attacker can actually achieve their objective
• Continuous-Q®: our continuous testing programme ensures that new risks are identified quickly, even between annual tests
• Independent advice: we are not tied to software vendors, which means our findings are always objective and pragmatic

Want to know which risks your organization faces that fall outside the scope of standard scanners? Contact us for a no-obligation conversation.

Lees meer

Vulnerability Management Versus Continuous Penetration Testing: What Is the Difference?

Geplaatst op: 25 October 2026

Vulnerability management and continuous penetration testing are two different approaches to cybersecurity testing, and they complement each other rather than replace one another. Vulnerability management focuses on systematically identifying and tracking known vulnerabilities in an IT environment, while continuous penetration testing actively and repeatedly simulates how an attacker would exploit those vulnerabilities. The difference lies in depth, frequency, and perspective: one measures, the other tests.

Which approach best suits your organization depends on your risk level, your responsibility to clients and partners, and the maturity of your security program. In this article, we answer the most frequently asked questions about both methods.

What does vulnerability management actually do for an organization?

Vulnerability management is a continuous process in which an organization systematically scans its IT environment for known weaknesses, prioritizes those weaknesses based on severity, and follows up on remediation. It provides a structured overview of technical risks across networks, systems, and applications, enabling security teams to act in a targeted manner.

In practice, vulnerability management revolves around four recurring steps:

1. Inventorying all assets in the environment, from servers and endpoints to cloud services
2. Scanning for known vulnerabilities using CVE databases and other threat intelligence
3. Prioritizing based on risk, so that critical vulnerabilities are addressed first
4. Remediating and monitoring, including verification that a vulnerability has actually been resolved

The major advantage of vulnerability management is its breadth and regularity. Automated vulnerability scans can quickly search large environments and provide an up-to-date picture of security hygiene. What they do not do is determine whether a vulnerability is actually exploitable in practice, or how attackers would combine multiple weaknesses to penetrate further.

How does continuous penetration testing work and what makes it ‘continuous’?

Continuous penetration testing is an approach in which ethical hackers simulate attacks on an organization’s systems at regular intervals, or even on an ongoing basis. What makes it “continuous” is that it is not limited to a one-time test, but becomes a structural part of the security program, aligned with the pace at which threats and the IT environment itself evolve.

Where a traditional pentest delivers a snapshot, continuous pentesting provides a living picture of actual resilience. Cybercriminals develop new attack techniques throughout the year. An annual test is therefore comparable to a photograph of a moving target: accurate at the moment of capture, but quickly outdated.

With continuous penetration testing, findings are continuously reported and followed up, so that vulnerabilities are discovered and remediated before attackers can exploit them. This requires a different mindset: security as a living capability, not an annual checkbox. You can read more about this approach on the page about continuous testing with Continuous-Q.

What are the key differences between vulnerability management and continuous pentesting?

The core difference between vulnerability management and continuous penetration testing lies in what they measure and how deep they go. Vulnerability management flags known weaknesses in an environment; continuous pentesting assesses whether those weaknesses are exploitable in practice and how far an attacker could get with them.

The key differences at a glance:

• Method: Vulnerability management is largely automated; continuous pentesting combines automated tools with manual investigation by ethical hackers
• Depth: Vulnerability scans flag issues based on known CVEs; pentests also uncover complex attack chains and logical vulnerabilities that tools miss
• Perspective: Vulnerability management looks at the environment from the inside; continuous pentesting adopts the perspective of an attacker
• Frequency: Vulnerability scans can run daily or weekly; pentests are more intensive and are scheduled based on risk level and changes in the environment
• Output: Vulnerability management produces a list of known risks; pentesting delivers proof of actual exploitability and concrete attack scenarios

In short: vulnerability management tells you what is vulnerable; continuous pentesting tells you how serious that actually is.

When is vulnerability management sufficient and when is it not?

Vulnerability management is sufficient when an organization primarily wants to maintain a healthy baseline security posture, meets standard compliance requirements, and does not have a particularly high risk profile. As soon as the organization manages sensitive data, bears responsibility for third parties, or operates in a sector with an elevated threat level, vulnerability management alone falls short.

Vulnerability management provides no answer to questions such as: “Can an attacker gain access via our VPN and move laterally through our network?” or “Are our security measures capable of withstanding a targeted attack?” These questions require actual simulation.

Organizations for which vulnerability management alone is insufficient include:

• Managed Service Providers, who have access to multiple client environments through their infrastructure
• Organizations that fall under NIS2 or other regulations requiring demonstrable resilience
• Companies that process critical or confidential data, such as financial or medical information
• Organizations that have recently been affected by an incident or have implemented a significant change to their IT environment

For more insight into compliance obligations and what they mean for your testing policy, the page on compliance and policy offers practical guidance.

Can vulnerability management and continuous pentesting be used together?

Yes, vulnerability management and continuous penetration testing work best when deployed together. They are complementary: vulnerability management provides the breadth and regularity needed to maintain security hygiene, while continuous pentesting delivers the depth to test whether that security holds up under real attack pressure.

In a mature security program, vulnerability management feeds the pentest strategy: discovered vulnerabilities are validated and placed in context by ethical hackers, who then determine which combinations of weaknesses pose the greatest risk. Conversely, pentest findings guide prioritization within the vulnerability management process.

For organizations with a high risk profile, such as Managed Service Providers, the combination is not a luxury but a necessity. An MSP serving one client is in effect also protecting all other clients in its portfolio. This requires both broad monitoring and regular, in-depth attack simulations. Additionally, red teaming can add a valuable layer for organizations that want to test their resilience even further.

How Q-Cyber helps with vulnerability management and continuous pentesting

At Q-Cyber, we combine technical depth with pragmatic advice, so that you not only know what is vulnerable, but also what you can concretely do about it. Our approach includes:

• Manual pentests performed by certified ethical hackers, who go beyond automated scans and expose complex attack chains
• Continuous-Q®, our continuous testing program specifically developed for Managed Service Providers and organizations with an elevated risk profile
• Clear reports with concrete priorities, so you immediately know where action is required
• Independent advice, without dependency on software vendors or suppliers
• Compliance guidance, including NIS2 questions and policy development around cybersecurity testing

Want to know which approach best suits your organization? Contact Q-Cyber for a no-obligation conversation.

Lees meer

What Is the Difference Between Automated and Manual Penetration Testing?

Geplaatst op: 24 October 2026

The most important difference between automated and manual penetration testing lies in depth and creativity. Automated tools quickly scan for known vulnerabilities and configuration errors, but lack the reasoning needed to combine multiple weaknesses into a single attack chain. A human pentester thinks like an attacker, and that makes a fundamental difference.

Both methods have their place in a healthy security strategy. The choice between automated and manual penetration testing depends on your goal, budget, and the maturity of your IT environment. In this article, we answer the most frequently asked questions about both testing methods.

When does automated penetration testing fall short?

Automated penetration testing falls short as soon as an attacker does more than executing known attacks against known vulnerabilities. Automated tools excel at detecting Layer 1 issues: known CVEs, missing patches, and public exploits. But they stop exactly at the point where things get interesting.

The core problem is that automated tools assess findings in isolation. They report a misconfiguration in Azure, an overly permissive permission, or a weak identity setting each as a separate finding. What they do not do is investigate what happens when all those small weaknesses are combined.

Imagine: an SSRF vulnerability appears low risk on its own. But combined with a managed identity, broad Azure RBAC permissions, and access to a Key Vault, that same vulnerability can lead to full access to cloud resources. An automated tool sees four separate findings. An attacker sees one attack path. This is exactly the blind spot of automated testing.

In addition, automated tools lack context. They do not understand which systems are business-critical, which user accounts have elevated privileges in practice, or how processes and people are interconnected. They test what they can reach, not what a targeted attacker would try to reach.

What can a human pentester do that a tool cannot?

A human pentester can discover attack paths by combining multiple weaknesses, reasoning creatively, and understanding the context of an organization. Where a tool stops at individual findings, an experienced pentester investigates how those findings together form a route to critical systems.

This directly connects to a fundamental truth in offensive security: attackers do not see findings, they see attack paths. A human pentester thinks from that same logic. They do not ask “is this vulnerable?” but “how can I use this to get further?”

Concrete advantages of a human pentester include:

• Recognizing correlated attack paths where multiple low-severity findings together form a critical risk
• Testing logic within applications, such as insecure authorization flows that have no known CVE
• Simulating targeted attacks specifically tailored to your environment and sector
• Understanding human and organizational factors, such as which employees have access to which systems
• Discovering vulnerabilities in new or custom solutions that are not yet in databases

Want to know how far an attacker could actually get in your environment? Then red teaming offers an even more advanced simulation of a targeted attack, also incorporating social engineering and physical access.

How does the output of both testing methods differ?

The output of automated penetration testing typically consists of a list of known vulnerabilities, sorted by severity, with references to CVE databases and standard recommendations. The output of manual testing contains in-depth analyses of attack paths, contextual risk assessments, and concrete recommendations tailored to your specific environment.

This difference is greater than it appears. An automated report can contain hundreds of findings, but offers little guidance on what is truly dangerous. A finding with a high CVSS score may be barely exploitable in your environment, while a finding with a low score can still lead to a data breach via an attack path.

A manual pentest report answers the questions that truly matter:

• Which findings are dangerous in combination, even if they appear harmless individually?
• What is the most realistic attack route to our crown jewels?
• Which action has the greatest impact on our actual security?

In short: automated testing delivers volume, manual testing delivers insight.

When do you choose automated, and when do you choose manual testing?

Choose automated penetration testing when you want to quickly and regularly check whether known vulnerabilities are present, patches have been correctly applied, and the basic hygiene of your environment is in order. Choose manual testing when you want to know whether a targeted attacker could actually cause damage in your specific environment.

A practical guideline:

• Automated testing is suitable for continuous monitoring, compliance checks, and quickly validating changes to your infrastructure
• Manual testing is necessary when introducing new systems or applications, after major infrastructure changes, or when you want a realistic picture of your resilience against targeted attacks
• Both are relevant if you operate in a sector with high security requirements, such as financial services, healthcare, or as a managed service provider

The number of vulnerabilities found says little about how secure you are. An environment with twenty automatically discovered findings can be safer than one with five, if those five lead via an attack path to full access to your cloud environment.

What are the cost differences between both methods?

Automated penetration testing is considerably cheaper than manual testing, because it largely runs on tools that operate without human intervention. Manual penetration testing requires specialized expertise and time, which makes the costs higher but also delivers a qualitatively different outcome.

The costs of automated scans range from a few hundred to several thousand euros per year, depending on the size of the environment and the frequency of the scans. A manual pentest typically costs more, but provides insight that no automated tool can achieve.

Important to factor in: the cost of a pentest is low compared to the cost of a successful attack. Think of recovery costs, reputational damage, fines under legislation such as NIS2 compliance, and operational downtime. From that perspective, manual testing is not a cost, but an investment in continuity.

How does a hybrid approach work in practice?

A hybrid approach combines automated scans for continuous monitoring with periodic manual pentests for in-depth insight. In practice, this means that automated tools continuously monitor basic hygiene, while human pentesters periodically investigate whether attack paths exist that tools do not see.

This is also the approach that best aligns with the reality of modern cyber threats. Cybercriminals develop new techniques throughout the year. An annual pentest is nothing more than a snapshot against that — a photo of a moving target. The combination of continuous automated monitoring and regular manual testing ensures that your security posture evolves alongside the threat landscape.

In practice, a hybrid approach often looks like this:

1. Continuous automated vulnerability scans across the entire environment
2. Periodic manual pentests focused on specific systems, applications, or attack paths
3. Follow-up on findings with concrete remediation and retesting
4. Structural integration of security testing into development and management processes

Want to know more about how continuous testing works as a structural program? Read more about Continuous-Q, an approach where testing is not a one-time event but an ongoing process.

How Q-Cyber helps with penetration testing

At Q-Cyber, we combine the speed of automated scanning with the depth of manual pentesting. We do not only look at individual vulnerabilities, but investigate how those vulnerabilities together form attack paths that lead to real damage. That is the difference between a list of findings and genuine insight into your risk profile.

What we offer:

• Manual pentests carried out by certified ethical hackers who think like attackers
• Analysis of correlated attack paths, not just individual findings
• Clear reporting with prioritized recommendations, immediately actionable
• Independent advice without dependency on software vendors or suppliers
• The option to start with Continuous-Q for ongoing security

Want to know where your organization is vulnerable, and how an attacker would combine those vulnerabilities? Get in touch and we will discuss which approach best fits your situation.

Lees meer

Why Are Identities Interesting to Hackers?

Geplaatst op: 23 October 2026

Every day, attackers attempt to gain access to the systems of organizations worldwide. What surprises many people is that they rarely need to start with a sophisticated technical attack. In most cases, they begin somewhere else: with identities. Accounts, credentials, and access rights are at least as valuable to hackers as an unpatched system — and often far easier to exploit.

In this article, you will learn step by step why digital identities are so attractive to attackers, how they obtain them, and what happens next. We conclude with practical guidelines for better protecting identities within your organization.

What exactly is a digital identity?

A digital identity is the combination of data that a system uses to determine who you are and what you are allowed to do. In its simplest form, this consists of a username and a password. But in practice, a digital identity is much broader.

Consider an employee who logs into a cloud environment such as Microsoft 365. That employee has an account, but that account also has roles, rights, and permissions: access to certain folders, the ability to create other users, or the right to approve invoices. All of these elements together form the digital identity of that person within the organization.

In addition to human identities, there are also so-called service accounts and machine identities: accounts used by applications, scripts, or automated processes. These accounts often have broad permissions and are monitored less closely than employee accounts. That makes them especially interesting for attackers.

• Employee user accounts, including their roles and permissions
• Administrator accounts with elevated privileges
• Service accounts used by applications
• Machine identities in cloud platforms such as Azure or AWS

Why are identities the preferred target of attackers?

Now that you know what a digital identity entails, you also better understand why attackers are so focused on them. A stolen identity gives an attacker something that technical exploits rarely offer: legitimately appearing access.

When an attacker exploits a vulnerability in software, it almost always leaves traces in log files and security systems. But when that same attacker logs in using the valid credentials of an employee, they appear at first glance to be a regular user. Security systems that detect anomalous behavior then have a much harder time raising the alarm.

Moreover, whoever holds the identity holds the rights that come with it. An attacker who obtains the identity of an IT administrator potentially gains access to servers, cloud environments, backup systems, and sensitive customer data. This makes identity-based attacks particularly efficient from an attacker’s perspective.

A useful analogy: stealing a key is far quieter than breaking in through a window. And if that key also grants access to multiple floors of a building, the appeal is even greater. The same applies to digital identities and cybersecurity identity management.

How hackers obtain identities

There are multiple ways in which attackers manage to acquire digital identities. Not all of these methods are equally technical, which is precisely what makes them effective against organizations that invest only in technical security.

Phishing and social engineering

The most common method is phishing: an attacker sends a fake email that appears to be a legitimate message from a bank, a colleague, or a well-known service. The recipient clicks a link and enters their credentials on a fake page. The attacker now has the credentials and can log in directly. No technical exploit required.

Credential stuffing

With credential stuffing, an attacker uses lists of leaked passwords from other data breaches. Many people use the same password across multiple platforms. If a password was ever leaked through a webshop, the attacker will try that same password on corporate systems as well. This is one of the reasons why password reuse is so dangerous.

Identity weaknesses and misconfigurations

In addition to directly stealing credentials, attackers also look for weaknesses in how identities are configured. Think of accounts with overly broad permissions, service accounts without password rotation, or cloud configurations where certain roles are automatically assigned. These are not classic software vulnerabilities, but they do offer an attacker a viable path to sensitive systems. For more insight into how attackers identify these kinds of weaknesses, red teaming is a valuable approach.

Supply chain via MSPs

A less obvious attack path runs through the supply chain. Managed Service Providers (MSPs) often have access to the systems of dozens of clients simultaneously. Anyone who manages to steal the identity of an MSP employee potentially gains access to all of those client environments. This makes compromising an MSP particularly attractive for attackers looking for scale.

What hackers do after stealing an identity

Stealing an identity is not the end goal for an attacker — it is the starting point. What happens next often determines the extent of the damage.

Once an attacker has access via a stolen account, they begin by exploring the environment. They examine what rights the account has, which systems are reachable, and whether there are opportunities to expand those rights further. This is called privilege escalation: moving from an account with limited rights to one with administrator privileges.

The attacker then combines what they have found. An account with limited rights may seem harmless on its own. But if that account also has access to a cloud resource with a misconfiguration, and that misconfiguration provides access to a key vault containing sensitive keys, then the combination of those three small weaknesses together is sufficient for full access to critical systems. Attackers do not see individual findings — they see attack paths.

In the final phase, an attacker executes their actual objective: stealing data, installing ransomware, sabotaging systems, or leaving a backdoor for future use. Because they behave like a legitimate user, this process can last weeks or even months without being noticed. A thorough pentest can expose these kinds of attack paths before a real attacker exploits them.

How organizations effectively protect identities

Now that it is clear how attackers operate, the question is: what can you as an organization do about it? Effective protection of digital identities requires more than just strong passwords. It is about a coherent approach combining technical measures, policy, and awareness.

Multi-factor authentication as a base layer

Multi-factor authentication (MFA) is one of the most effective measures against credential theft. Even if an attacker obtains a password, they cannot gain access without the second factor. MFA is now available for virtually all business platforms and forms an essential part of cybersecurity identity management.

The principle of least privilege

Give accounts only the rights they actually need for their role. This is called the principle of least privilege. An employee who processes invoices does not need administrator rights on the server environment. By limiting rights, you automatically limit the damage an attacker can cause with a stolen identity.

Monitoring and behavioral analysis

Technical measures alone are not sufficient. It is also important to monitor whether accounts behave as expected. Is an employee suddenly logging in from another country? Is a large amount of data being downloaded outside of office hours? These kinds of anomalies can be signals of misuse of a stolen identity.

Regular review of permissions

Permissions grow organically over time in most organizations. Employees receive extra rights for a project and those rights are never revoked. A periodic review of who has access to what is a simple but effective measure. Read more about how policy and structure help with this on the page about compliance and policy.

Employee awareness

Because phishing remains one of the most widely used methods for stealing identities, employee awareness is crucial. Employees who recognize suspicious emails and know how to respond form an important line of defense. Technology can do a great deal, but human behavior remains a determining factor in the security of digital identities.

How Q-Cyber helps protect identities

Protecting identities requires insight into how attackers think and how your environment looks from the outside. That is precisely what we at Q-Cyber focus on. We help organizations not only with finding technical vulnerabilities, but also with uncovering the attack paths that arise from combinations of identity weaknesses, overly broad permissions, and misconfigurations.

What we concretely offer:

• Manual pentests in which our ethical hackers think like a real attacker, including examining identities and permissions
• Red teaming in which we simulate realistic attack scenarios to test how far an attacker can get via stolen identities
• Advice and policy development around identity management, least privilege, and access control
• Continuous insight via our Continuous-Q program, so you know where you stand even between test moments

Want to know how your organization scores in the area of identity security? Contact us and we will look together at the risks most relevant to you.

Lees meer

What Is the Difference Between Severity and Exploitability?

Geplaatst op: 22 October 2026

The difference between severity and exploitability determines how dangerous a vulnerability truly is in practice. Severity describes the potential impact if a vulnerability is exploited, while exploitability indicates how easily an attacker can actually carry out that exploitation. Both scores together provide a far more realistic picture of risk than either one alone. In this article, we answer the most important questions about how to interpret these scores and how to set the right priorities based on them.

How do you determine which vulnerability is the most dangerous?

The most dangerous vulnerability is not automatically the one with the highest severity score. A vulnerability is only truly dangerous when it both has a large potential impact and is relatively easy for an attacker to exploit. The combination of severity and exploitability determines the actual risk to your organization.

Many organizations make the mistake of looking exclusively at the severity of a vulnerability on paper. A vulnerability with a critical CVSS score of 9.8 sounds alarming, but if that vulnerability can only be exploited from an internal network that no attacker has access to, the actual risk is considerably lower. Conversely, a vulnerability with a lower score can be urgent if it is easily exploitable remotely and provides access to sensitive systems.

Attackers do not think in lists of findings. They look for the path of least resistance: the combination of weaknesses that gets them to their goal the fastest. This means that when assessing vulnerabilities, you should always ask: how does this finding fit into a broader attack chain?

What exactly does the CVSS score measure?

The CVSS score, or Common Vulnerability Scoring System score, is a standardized method for measuring the severity of a vulnerability on a scale of 0 to 10. The score combines multiple factors, including the attack vector, the required privileges, user interaction, and the impact on confidentiality, integrity, and availability.

The CVSS score is built from three groups of metrics:

• Base metrics: the inherent properties of the vulnerability itself, such as whether it can be exploited remotely and what impact it has on a system
• Temporal metrics: factors that change over time, such as the availability of a public exploit or a patch from the vendor
• Environmental metrics: adjustments based on the specific environment of your organization, such as how critical the affected system is

In practice, most tools and reports use only the base score, without taking into account temporal or environment-specific context. This makes the score useful as a first indication, but insufficient as a basis for prioritization. A CVSS score says something about the potential severity of a vulnerability, but nothing about the specific situation of your organization or the likelihood that an attacker will actually exploit that vulnerability.

Why does a critical severity sometimes have low priority?

A critical severity score does not always justify immediate action, because the score does not take into account the specific context of your environment. If a vulnerability with a high CVSS score can only be exploited via direct physical access, or only applies to software you do not use at all, the actual threat is minimal.

There are several reasons why a vulnerability with a high severity score may still receive low priority:

• The affected system is not reachable from the internet or from the network segment where an attacker is located
• There is no known public exploit for the vulnerability
• Compensating controls are active, such as network segmentation or additional authentication requirements
• The system contains no sensitive data and is not critical to business operations
• The vulnerability requires a high level of privileges that an attacker realistically does not have

This is precisely why manual pentesting is more valuable than a purely automated vulnerability scan. A scanner reports based on the CVSS score; an experienced tester assesses whether a vulnerability is actually exploitable in your specific environment.

How do attackers use exploitability when choosing a target?

Attackers evaluate exploitability as one of the first filters when choosing an attack path. They look for vulnerabilities that are remotely exploitable, require no or minimal privileges, require no user interaction, and for which public exploits or tools are available. The lower the barrier, the more attractive the target.

A good example is the difference between a vulnerability that an attacker can exploit remotely without any authentication, and a vulnerability that only works if the attacker already has administrator privileges. The first has high exploitability and immediately attracts the attention of automated attack tools and opportunistic attackers. The second requires the attacker to already be deep inside the system, which raises the barrier considerably.

What attackers also do — and what is often missed in traditional risk assessments — is combining multiple vulnerabilities with a low individual severity into one working attack path. A misconfigured cloud setting, combined with overly permissive permissions and a weak identity configuration, can together lead to full access to cloud resources, while none of the three findings is considered critical on its own. Attackers do not see isolated findings. They see attack paths.

What factors determine whether a vulnerability is truly exploitable?

Whether a vulnerability is actually exploitable depends on a combination of technical and environment-specific factors. The most important ones are the attack vector, the required privileges, the availability of a working exploit, and the presence of compensating security controls in your specific environment.

The key factors at a glance:

• Attack vector: is the vulnerability exploitable via the internet, via the local network, or only with physical access?
• Required privileges: does an attacker already need an account or administrator access to exploit the vulnerability?
• User interaction: does a user need to click or open something before the exploit works?
• Availability of exploits: does a public, working exploit exist, or is the technical knowledge required to write one limited?
• Compensating controls: are there firewalls, network segmentation, MFA, or other controls that reduce exploitability?
• Patch status: is a patch already available, and how quickly is it deployed within your organization?

Assessing all these factors together requires insight into how your environment is set up. A thorough security analysis goes beyond checking off CVE scores and assesses vulnerabilities in the context of your specific architecture, identities, and permissions.

How do you prioritize vulnerabilities based on both scores?

Effective vulnerability prioritization combines severity and exploitability in a risk model that also takes into account the context of your organization. The rule of thumb: prioritize vulnerabilities that both have a high impact and are relatively easy to exploit, and factor in how critical the affected system is to your business operations.

A practical framework for prioritization works in three layers:

1. Known vulnerabilities with public exploits: CVEs with a high CVSS score and an available public exploit require immediate action. These are the low-hanging fruit for attackers and should be addressed first.
2. Individual weaknesses in configuration and identities: misconfigured cloud settings, overly permissive permissions, and weak identity configurations often have a lower CVSS score but high exploitability in practice. They deserve a higher priority than their score suggests.
3. Correlated attack paths: the most dangerous category is often the combination of multiple small weaknesses that together form an attack path. No single finding appears critical on its own, but together they can lead to full access to systems or cloud resources.

When prioritizing, it is also important to consider which systems are most attractive to attackers and which are most critical to your organization. A vulnerability in an internal test system has a different priority than the same vulnerability in a production environment containing customer data.

Annual pentests provide a snapshot, but the environment changes continuously. New applications, modified permissions, and new vulnerabilities mean that a prioritization list quickly becomes outdated. Continuous insight into attack paths is therefore not a luxury but a necessity for organizations that take their security seriously.

How Q-Cyber helps assess severity and exploitability

At Q-Cyber, we believe that a list of vulnerabilities only has value when you understand which of them are truly exploitable in your specific environment. That is why we assess vulnerabilities not only based on CVSS scores, but in the context of your architecture, identities, permissions, and attack paths.

What we concretely do:

• We conduct manual pentests in which our ethical hackers think like a real attacker, including identifying correlated attack paths that automated scanners miss
• We assess vulnerabilities at three levels: known CVEs, individual weaknesses in configuration and identities, and combined attack paths
• We deliver concrete prioritization based on both severity and actual exploitability in your environment, not based on generic scores
• We provide continuous insight through Continuous-Q®, so you know where you stand not just on the day of the test but throughout the entire year
• We give pragmatic advice on which measures eliminate the most risk, independent of software vendors or suppliers

Want to know which vulnerabilities in your environment are truly exploitable and how to best prioritize them? Contact us and we will be happy to think along with you.

Lees meer

How Can Overly Broad User Permissions Lead to a Cyberattack?

Geplaatst op: 21 October 2026

Excessive user permissions are one of the most common causes of successful cyberattacks. When employees have access to systems, folders, or applications they don’t need for their work at all, it dramatically increases the attack surface. An attacker who compromises one account can rapidly move through to critical systems via surplus permissions. This is called privilege escalation, and it is a technique hackers apply on a daily basis.

In this guide, you’ll work through step by step how to address excessive user permissions, implement the least privilege principle, and transform access management from a one-time action into a continuous process. Every step is immediately actionable, even if your organization does not yet have a formal access policy.

Map existing user permissions

Before you can change anything, you need to know what exists. Many organizations have granted permissions over the years without maintaining a central overview. Accounts accumulate permissions after role changes, projects, or temporary exceptions that were never reversed. Start, therefore, with a complete inventory.

1. Export an overview of all active user accounts from your identity provider (such as Active Directory, Azure AD, or a comparable system).
2. Map out per account which permissions have been granted: local administrator rights, access to shared folders, application licenses, and cloud permissions.
3. Also note service accounts and shared accounts, as these are regularly overlooked during rights audits.
4. Compare the permissions found with the current role of each user.

After this step, you’ll have a concrete picture of the current situation. You’ll likely immediately encounter accounts with permissions that have long since ceased to be necessary. That is normal, but it is also exactly what an attacker is looking for. A manual pentest can further expose these kinds of hidden weaknesses.

Identify surplus and high-risk permissions

With the inventory in hand, you now analyze which permissions actually pose a risk. Not every redundant permission is equally dangerous, but some combinations can give an attacker direct access to critical systems. Hackers don’t look at isolated vulnerabilities, but at how they can combine multiple small weaknesses into a single working attack path.

1. Flag accounts with administrator rights that do not have an administrator role. These are direct risk factors.
2. Look for accounts belonging to departed employees or inactive users that are still active.
3. Pay attention to accounts with simultaneous access to multiple sensitive systems, such as financial data and HR systems.
4. Identify permissions that were granted for a temporary project but were never revoked.
5. Check service accounts for unnecessarily high permissions, as attackers are fond of abusing these accounts due to their high privileges and limited monitoring.

Prioritize your findings based on risk: the more sensitive the system to which access exists and the greater the likelihood of misuse, the more urgent the adjustment. This gives you a working list for the next step.

Establish role-based access profiles

Using the risk analysis as a foundation, you now establish role-based access profiles. This principle, also known as Role-Based Access Control (RBAC), ties permissions to roles rather than to individuals. This prevents permissions from being granted ad hoc and then forgotten. The least privilege principle is the guiding rule here: every user receives only the permissions needed to perform their own tasks.

1. Define the key role groups within your organization, such as employee, team lead, IT administrator, and management.
2. Determine per role group which systems, applications, and data must be accessible for day-to-day work.
3. Document each profile in an access matrix, so that future assignments can always be traced back to an approved profile.
4. Set up an approval process for exceptions, whereby temporary expansions of permissions always receive an expiry date.

A well-documented access matrix is also valuable for compliance and policy. When an auditor or regulator asks how your access management is structured, you have a clear answer at hand. Ensure the matrix is approved by both IT and management, so there is broad support for the implementation.

Implement changes in phases

Now that the profiles have been established, it is time to adjust the existing permissions. Do this in phases to limit disruptions. Adjusting all permissions at once risks employees suddenly losing access to systems they genuinely need, resulting in loss of productivity.

1. Start with the accounts that pose the highest risk: former employees, accounts with unnecessary administrator rights, and inactive service accounts.
2. Communicate in advance to the employees and managers involved which changes will be made and when.
3. Preferably implement the changes outside of office hours to minimize direct disruption to work.
4. Set up a helpdesk point where employees can go if they no longer have access to something after the change.
5. Document every change, including the date, who carried out the change, and which old permission was replaced by which new permission.

Expect reports to come in during the first week after a major change from employees who can no longer access something. That is normal and even a sign that the approach is working. Handle every report through the approval process you set up in the previous step, so that exceptions are always granted consciously and with documentation.

Check and validate the new permissions structure

After implementation, you validate whether the new permissions structure actually works as intended. This is a step that many organizations skip, but without validation you don’t know whether the changes have been implemented correctly or whether new gaps have emerged.

1. Perform spot checks by verifying for a selection of accounts whether the permissions match the established profile.
2. Test whether former permissions have actually been revoked by attempting to log in to systems that an account should no longer have access to.
3. Check the log files of your identity provider for unusual access attempts or error messages that may point to incorrect configurations.
4. Have an independent party carry out a technical review, so that you receive an objective assessment of the effectiveness of the new structure.

A technical security analysis can provide additional value here by investigating whether combinations of permissions still exist that together form an attack path. Individual permissions may each appear acceptable on their own, while in combination they still pose a serious risk.

Make access management a continuous process

Access management is not a one-time project. Every time an employee changes roles, a new system is introduced, or a supplier is granted temporary access, the permissions profile of your organization changes. Without a structural process, permissions will naturally grow out of control again, and with them the risk of a cyberattack via privilege escalation.

1. Schedule a permissions review at least every quarter in which you compare active accounts with the applicable access profiles.
2. Link role changes and departures directly to an automated process for adjusting or revoking permissions.
3. Set up alerts for unusual access patterns, such as login attempts outside of working hours or access to systems an account normally never uses.
4. Also periodically evaluate the access profiles themselves, as the needs of roles change along with the organization.

By structurally embedding access management in your security processes, you build dynamic resilience rather than a static defense that becomes outdated over time. Combine this with periodic technical tests to verify whether the measures also hold up in practice.

How Q-Cyber helps address excessive user permissions

We see across organizations of all sizes that excessive user permissions are one of the most underestimated risk factors. An attacker who compromises one account often has access to critical systems within a short time via surplus permissions, without any spectacular technical exploit being required. We help organizations address this risk structurally.

• Pentests: Our ethical hackers investigate your environment the way a real attacker would, including mapping attack paths via identity and permission weaknesses that standalone vulnerability scanners miss.
• Advisory and policy development: We help you draw up an access matrix, set up RBAC profiles, and write policy that aligns with your organizational structure.
• Continuous-Q®: Through our Continuous-Q® program, we maintain continuous visibility into changes in your environment after the initial pentest, so that new risks are identified before an attacker discovers them.
• Independent: We are not tied to software vendors or suppliers, which means our advice is always in your best interest.

Want to know how your organization currently stands when it comes to access permissions and privilege escalation? Contact us for a no-obligation conversation.

Lees meer

Which Parts of a Pentest Require Human Expertise?

Geplaatst op: 20 October 2026

Some aspects of a pentest indispensably require human reasoning. Automated tools can quickly identify known vulnerabilities, but discovering complex attack chains, understanding business context, and creatively combining multiple weaknesses into a single dangerous attack path is reserved for an experienced ethical hacker. This article answers the most frequently asked questions about where human expertise makes the difference in a penetration test.

What can automated tools not discover during a pentest?

Automated tools miss attack chains that arise from the combination of multiple small weaknesses. They scan for known patterns and published vulnerabilities, but are blind to the creative connections a human attacker makes. It is precisely those connections that are most dangerous in practice, because no individual finding is then considered critical.

To understand this, it is useful to distinguish three layers within a manual pentest:

• Layer 1: Known vulnerabilities – Published CVEs, public exploits, and missing patches. This is the domain where automated scanners excel.
• Layer 2: Individual weaknesses – Incorrect cloud configurations, overly broad permissions, identity weaknesses, and insecure application settings. Tools partially pick this up, but miss the context.
• Layer 3: Correlated attack paths – The combination of multiple small findings that together lead to full access. This is the level where automated tools structurally fall short.

A concrete example makes this clear. Suppose a scanner reports four separate findings: an SSRF vulnerability, a managed identity with broad permissions, an Azure RBAC misconfiguration, and access to a Key Vault. Each of these findings seems manageable on its own. But a human tester sees how they chain together, leading to the role of subscription owner, with full control over cloud resources as a result. Attackers don’t see isolated findings. They see attack paths.

Which pentest phases are most dependent on human reasoning?

The reconnaissance, privilege escalation, and reporting phases are most strongly dependent on human expertise. In the reconnaissance phase, an ethical hacker decides which information is relevant and which attack vectors are worth exploring. During privilege escalation, creative connections are made that no script can produce. And in reporting, technical depth is translated into actionable business advice.

During the reconnaissance phase, it is not just about gathering information, but about interpreting it. Which employee likely has overly broad permissions? Which application was recently changed and is therefore potentially vulnerable? These are questions that require context, not computing power.

In the exploitation phase, the difference is even greater. An automated tool executes known exploits against known vulnerabilities. A human tester adapts techniques to the specific environment, improvises based on what they encounter, and thinks about what an attacker with a specific goal would do. That is precisely the difference between an automated scan and red team ethical hacking.

How does an ethical hacker think differently from an automated scanner?

An ethical hacker thinks in a goal-oriented and contextual way. Rather than assessing each vulnerability in isolation, a human tester asks: what does an attacker want to achieve, and which path leads there most quickly? That goal-oriented way of thinking is fundamentally different from the pattern-recognition model of an automated scanner.

Scanners work on the basis of signatures and known rules. They compare what they find with a database of known vulnerabilities and report matches. That is valuable for basic checks, but the model is by definition reactive: a vulnerability must already be known before a tool can recognise it.

An ethical hacker works differently. They combine technical knowledge with creativity, adapt their approach based on what they discover along the way, and think from the perspective of a real attacker. They ask questions such as: why is this port open, who has access to this data, and what could I do if I had that access? That kind of reasoning cannot be automated.

Moreover, a human tester understands the business context. A misconfiguration in a test environment is less urgent than the same misconfiguration in a production environment that processes customer data. A scanner does not make that distinction. An ethical hacker does.

When is an automated scan sufficient and when is it not?

An automated scan is sufficient for basic checks on known vulnerabilities, patching, and standard configurations. As soon as an organisation wants to know whether it can withstand a targeted attacker, or when the environment is complex, cloud-based, or heavily intertwined with external parties, an automated scan falls short.

Concrete situations in which an automated scan is adequate:

• Periodic checks to verify that patches have been correctly applied
• Quick inventory of known CVEs in a stable environment
• Compliance checks where a baseline is required

Situations in which a manual penetration test is necessary:

• Complex cloud environments with multiple identities and roles
• Organisations that work with sensitive customer data or critical infrastructure
• Environments that have recently been changed or expanded
• When you want to know how far an attacker can actually get
• Managed Service Providers that bear responsibility for the security of their clients

The number of vulnerabilities found says little about how secure an organisation truly is. That is one of the most underestimated insights in cybersecurity. Ten low-severity findings that together form a critical attack path are more dangerous than one high-severity finding that connects to nothing.

Why does an annual pentest provide an incomplete picture?

An annual pentest is nothing more than a snapshot of a moving target. Cybercriminals develop new attack techniques throughout the year, while an annual test captures the situation at only one specific moment. In the months that follow, the environment changes, systems are updated, and new vulnerabilities emerge that go unnoticed until the next test.

The problem is not that an annual pentest is bad. The problem is that organisations believe they are secure after such a test. But security is not a destination. Attackers do not come around once a year. They try continuously, looking for the moment when a new vulnerability has not yet been discovered or a recent configuration change has inadvertently created a gap.

Moreover, the environment of most organisations is constantly changing. New applications are rolled out, employees receive different permissions, and cloud configurations are adjusted. Every change can open a new attack path that did not exist at the time of the previous test. A continuous testing programme closes that gap, because it measures security the way attackers also work: continuously and adaptively.

How Q-Cyber helps with human expertise in pentesting

At Q-Cyber, certified ethical hackers carry out penetration tests that go beyond what automated tools can offer. We look not only at individual vulnerabilities, but at the complete attack chain. That is precisely the level at which real attackers operate, and therefore also the level at which a good pentest must work.

What we offer:

• Manual penetration tests carried out by experienced ethical hackers who think like an attacker
• Attack path analysis in which multiple small vulnerabilities are combined into a realistic attack scenario
• Clear reporting with concrete priorities, so you immediately know where action is required
• Continuous-Q® for organisations that want continuous insight into their actual security level
• Independent advice without dependency on software vendors or other suppliers

Want to know how secure your organisation truly is? Contact us and discover what a manual pentest by Q-Cyber can do for you.

Lees meer

How Does an Attack Path Arise Within Microsoft Azure?

Geplaatst op: 19 October 2026

An attacker who gains access to your Microsoft Azure environment rarely operates through a single major vulnerability. In most cases, they combine small weaknesses, misconfigurations, and identity issues into a connected route toward your organization’s crown jewels. That is an attack path: a series of steps an attacker can take to move from limited access to full control. Understanding how such an attack path arises is the first step toward breaking it.

In this guide, you will walk through the complete process of analyzing an Azure attack path: from preparation to validation and remediation. Whether you are conducting an Azure pentest, performing a security review, or simply want to better understand how attackers think, these steps give you a concrete framework to work with.

What you need to analyze an attack path

Before you begin the actual analysis, make sure you have the right access and tools at hand. An attack path analysis of an Azure environment requires insight into the configuration of the tenant, the identities, and the permissions. Without that foundation, you cannot draw reliable conclusions.

These are the minimum requirements for a thorough analysis:

• Read access to the Azure tenant via the Azure Portal or via the Azure CLI
• Access to Microsoft Entra ID (formerly Azure Active Directory) for identity and role data
• A tool for visualizing permissions and relationships, such as BloodHound for Azure (AzureHound) or Microsoft’s own tools such as Defender for Cloud
• Insight into the scope: which subscriptions, resource groups, and services fall within the assessment?
• Documentation of existing security controls, such as Conditional Access policies and MFA settings

Also make sure you have clearly defined the scope before you start. An Azure environment can be large and complex. By determining in advance which components you are analyzing, you avoid getting lost in details that fall outside the relevant attack surface.

Map Azure identities and permissions

Most Azure attack paths start with identities. Attackers look for accounts with excessive permissions, service principals with unmanaged credentials, or managed identities that have more permissions than strictly necessary. The first step is therefore a complete overview of who or what has access to what.

1. Export all users, groups, and service principals from Microsoft Entra ID via the Azure Portal or via PowerShell with the Get-AzureADUser and Get-AzureADServicePrincipal cmdlets.
2. Inventory the role assignments per subscription and resource group via Get-AzRoleAssignment. Pay specific attention to broad roles such as Owner, Contributor, and User Access Administrator.
3. Use AzureHound to automatically collect the relationships between identities, groups, and resources and visualize them in BloodHound. This makes it easier to see indirect permissions and group memberships.
4. Identify service principals with client secrets or certificates that have not been rotated in a long time, or that have owner rights on resources.

After this step, you have a complete picture of the identity landscape within the Azure environment. You will likely encounter accounts and principals that have more rights than expected. That is normal, and exactly what attackers find too. Note all anomalies for the next step.

Identify weak links in the chain of trust

With the permission map in hand, you now look for the weak links: the points in the chain where an attacker can gain a foothold and move further from there. In Azure pentests, these are the most common weak points that attackers actively exploit.

Check the following categories systematically:

• Misconfigured Conditional Access policies: are there users or locations that are excluded from MFA? Are there legacy authentication protocols still active that bypass MFA?
• Overprivileged accounts: does an account have Owner rights on a subscription while it only manages a specific application?
• Managed identities with broad scope: a managed identity assigned to a VM with Contributor rights on the entire subscription is an attractive target.
• Public storage with sensitive data: Azure Blob Storage containers that are publicly accessible and contain configuration files, credentials, or certificates.
• Unmanaged app registrations: applications in Entra ID with high API permissions and credentials that are no longer actively managed.

Link each weak link to the identities and permissions you inventoried in the previous step. This way you start to see the outlines of possible attack paths: an attacker who gains access to account A can, via group membership B, take over the rights of principal C, and thereby reach resource D.

Simulate the attack route step by step

Now that you know where the weak links are, it is time to reason like an attacker. The goal of this step is not to test arbitrary vulnerabilities, but to determine which combination of weaknesses leads to a working attack path toward a valuable target, such as a database with customer data, a key vault with secrets, or Global Administrator rights in Entra ID.

Walk through the simulation as follows:

1. Choose a realistic starting point for the attacker: a compromised user account with limited rights, or a leaked service principal credential.
2. Define the end goal: which resource or permission level is most valuable to an attacker in this environment?
3. Map the route from starting point to end goal, step by step. Which permissions are needed? Which intermediate resources or identities are used?
4. Technically validate each step: is the permission actually present? Can the attacker perform the action without additional authentication or approval?
5. Pay specific attention to privilege escalation opportunities: situations where an attacker with limited rights can grant themselves higher rights, for example via a misconfigured role assignment or an overprivileged managed identity.

A common Azure attack path in practice looks like this: an attacker compromises a user account without MFA via a phishing attack, discovers that this account is a member of a group with Contributor rights on a subscription, finds via that access a storage account with a configuration file containing credentials for a service principal with Owner rights, and then takes full control of the environment. Each step individually seems manageable, but the combination makes it dangerous. More background on how attackers build these kinds of routes can be found in our cyber research.

Validate and document the attack path

After identifying a potential attack path, thoroughly validate the finding before drawing conclusions. An attack path that seems technically possible but is blocked in practice by a compensating control is not a working path. Conversely, a path you overlook because you have not validated a step can be a critical risk.

1. Actually execute each step in the attack route in a controlled test environment, or verify the permissions via the Azure Portal and CLI without actually triggering the action.
2. Check whether compensating controls block the path: are there Azure Policies that prohibit certain actions? Are there alerts configured that would make the attack route visible?
3. Document the path visually: draw the route with the involved identities, permissions, and resources. BloodHound makes this automatically insightful for complex environments.
4. Classify the severity based on impact (what can an attacker achieve?) and exploitability (how difficult is the path to traverse?).

Good documentation is essential, not only for the people who need to resolve the attack path, but also for management that needs to set priorities. A clearly documented attack path shows why a combination of weaknesses is more dangerous than the individual components suggest. That is precisely the difference between a list of individual vulnerabilities and a real attack path analysis.

Close the attack path with targeted measures

With the attack path validated and documented, the final step is to actually close the route. The key here is to prioritize: not every weak link needs to be resolved immediately, but the link that most effectively breaks the attack path has the highest urgency. Focus on the step in the chain that is least complex to fix and has the greatest impact.

1. Remove or restrict overprivileged role assignments via the principle of least privilege: give accounts and service principals only the rights they actually need.
2. Enforce MFA for all accounts without exception, and block legacy authentication protocols via Conditional Access.
3. Rotate credentials of service principals and app registrations identified as weak links, and set up automatic rotation where possible.
4. Remediate misconfigurations in storage accounts, key vaults, and other resources that are unintentionally accessible.
5. Set up detection rules via Microsoft Defender for Cloud or Microsoft Sentinel that monitor the critical steps in the attack path, so that an attempted abuse becomes visible.

After implementing the measures, verify that the attack path has actually been closed by walking through the route again. A fix that looks correct on paper but has not been properly implemented in practice gives a false sense of security. Repeat the validation step until the path is demonstrably blocked. Keep in mind that Azure environments are constantly changing: new resources, adjusted permissions, and new accounts can open a new attack path as early as tomorrow. One-time testing is therefore rarely sufficient. More about how to approach this structurally can be found on the page about Continuous-Q.

How Q-Cyber helps with analyzing Azure attack paths

An attack path analysis of a Microsoft Azure environment requires technical depth, knowledge of identity and permission structures, and the ability to reason like a real attacker. That is precisely what we specialize in. We do not run automated scans that produce a list of individual vulnerabilities, but investigate how an attacker can combine various weaknesses into a working attack path toward your organization’s crown jewels.

What we concretely offer for Azure environments:

• A manual pentest focused on Azure identities, permissions, and cloud misconfigurations
• Full attack path analysis including visualization of the attack route
• Insight into privilege escalation opportunities and weak links in the chain of trust
• A clear report with concrete priorities, focused on breaking the most critical attack paths
• Pragmatic remediation advice tailored to your specific environment and organization
• Optional: continuous monitoring of new attack paths via our red team and Continuous-Q program

Want to know how your Azure environment stands and which attack paths already exist? Get in touch and we will look together at the best approach for your situation.

Lees meer

What Is CVSS and How Is the Severity of a Vulnerability Determined?

Geplaatst op: 18 October 2026

When a new vulnerability in software is discovered, the immediate question arises: how serious is this, really? Is it a problem that needs to be resolved today, or can it wait until the next maintenance cycle? To answer that question in a structured and consistent way, the Common Vulnerability Scoring System exists, better known as CVSS. In this article you will learn what CVSS is, how the score is calculated, what the severity categories mean, and how to apply CVSS wisely within your own security practice.

We build the knowledge step by step: from the origin of the system, through the technical workings, to the practical application. By the end, you will understand not only what a CVSS score says, but also what it does not say, and why that distinction is crucial for good cybersecurity.

What is CVSS and where does it come from?

The Common Vulnerability Scoring System is an open standard for assessing the severity of vulnerabilities in software and systems. The system provides a standardized way to compare vulnerabilities, regardless of the type of system or vendor where they were found.

CVSS was developed by the Forum of Incident Response and Security Teams (FIRST) and was first published in 2005. Since then, the system has been revised several times. The most widely used version is CVSS 3.1, but CVSS 4.0 is now available and introduces further refinements for more modern IT environments. The scores are published through the National Vulnerability Database (NVD) of the US government, which maintains a CVSS score for virtually every known vulnerability.

The goal of CVSS is simple: to provide a common language so that security teams, vendors, and organizations around the world can discuss the severity of a vulnerability in the same way. Without such a standard, every party would use its own measuring stick, making comparison and prioritization virtually impossible.

How does the CVSS score work and what do the base metrics measure?

A CVSS score is a number between 0.0 and 10.0, where a higher score indicates a more severe vulnerability. That score is calculated based on a set of metrics, divided into three groups: the base metrics, the temporal metrics, and the environmental metrics. The base metrics form the foundation and are applied most consistently.

The base metrics: what is being measured?

The base metrics describe the intrinsic characteristics of a vulnerability, independent of the specific context of an organization. They are divided into two categories:

• Exploitability: How easy is the vulnerability to exploit? This includes factors such as the attack vector (does the attacker need to be on the network, or can it be done via the internet?), the complexity of the attack, and whether special privileges or user interaction are required.
• Impact: What is the potential damage if the vulnerability is exploited? This is measured along three axes: confidentiality (can data be viewed?), integrity (can data be modified?), and availability (can the system be disrupted?).

A concrete example: a vulnerability that can be exploited remotely without authentication and grants full access to a system scores high on virtually all base metrics. A vulnerability that can only be exploited locally and exposes only limited information scores considerably lower.

Temporal and environmental metrics

In addition to the base metrics, there are temporal metrics that take into account the current exploitation status of a vulnerability. Is there already a working exploit available? Does a patch exist? These factors can adjust the effective score up or down. The environmental metrics go one step further and allow organizations to adjust the score based on their own IT environment and the value of the affected systems. For more depth on how vulnerabilities are tested in practice, it is useful to understand how a professional pentest works.

What do the severity categories mean in practice?

The numerical CVSS score is translated into five severity categories, which help with quickly assessing priority:

• None (0.0): No vulnerability or negligible risk.
• Low (0.1 – 3.9): Limited impact; exploitation is difficult or has few consequences.
• Medium (4.0 – 6.9): Moderate impact; exploitation requires specific circumstances.
• High (7.0 – 8.9): Serious vulnerability with significant potential damage.
• Critical (9.0 – 10.0): Maximum severity; immediate action required.

In practice, security teams use these categories as a first filter when prioritizing patches. A Critical vulnerability in a publicly accessible system typically receives the highest priority and requires swift action. A Low vulnerability in an internal system without sensitive data can be included in the regular maintenance cycle.

It is important to realize, however, that the severity category is a starting point, not a final verdict. The actual urgency always depends on the broader context, such as which system is involved, who has access to it, and how the system is connected to the rest of your environment.

Why is a high CVSS score not always the greatest danger?

This is perhaps the most important lesson you can take away from this article: a high CVSS score does not automatically mean that a vulnerability poses the greatest risk to your organization. And conversely, a low score can sometimes be misleading.

CVSS measures the severity of a vulnerability in isolation. The system does not account for the way vulnerabilities can be combined into an attack path. An attacker who has access to a system does not always need to exploit the most critical vulnerability. Sometimes a combination of a medium-score vulnerability, an incorrect permission setting, and a misconfiguration in the cloud is together more dangerous than a single standalone Critical vulnerability.

Consider the following: a poor-quality lock on a back door that nobody uses is less urgent than a slightly better lock on the front door that is always left open. CVSS tells you how bad the lock is, but not which door is most attractive to a burglar. For that insight you need a broader perspective, such as that provided by red team exercises or in-depth security research.

A common mistake is simply working through all vulnerabilities in order of CVSS score. You can resolve twenty Medium vulnerabilities and still remain exposed, because the combination of remaining low-score findings together forms a working attack path.

Applying CVSS within your own vulnerability management

Building on an understanding of what CVSS measures and what it does not measure, the next step is: how do you use the system effectively in practice? CVSS is an excellent tool when you treat it as one input in a broader assessment, not as the sole measure.

Effective vulnerability management based on CVSS works as follows:

1. Start with the base metrics as a filter: Use the CVSS score to create an initial prioritization. Critical and High vulnerabilities deserve prompt attention, especially if they are present in publicly accessible systems.
2. Add context: Ask yourself which system is involved, how sensitive the data it processes is, and how the system is connected to the rest of your environment. A Critical vulnerability in an isolated test system is less urgent than a Medium vulnerability in your customer database.
3. Look at attack paths, not just individual findings: Analyze how vulnerabilities can be combined. Are there combinations of low and medium vulnerabilities that together form a serious risk?
4. Keep an eye on the temporal metrics: If there is an active exploit in circulation for a vulnerability, that significantly increases the urgency, even if the base score is not extremely high.
5. Ensure continuous monitoring: Your environment changes constantly. New systems are added, configurations change, new vulnerabilities are discovered. A one-time assessment is therefore always just a snapshot in time. See how continuous security monitoring can help with this.

The goal is not to remediate every vulnerability with a high CVSS score first, but to identify the vulnerabilities that pose the greatest actual risk to your organization.

How Q-Cyber helps with assessing vulnerabilities

CVSS provides a valuable standard for assessing the severity of vulnerabilities, but it does not tell the full story. At Q-Cyber we understand that the real threat often does not lie in a single high score, but in the combination of vulnerabilities, misconfigurations, and permissions that together form an attack path.

This is how we help organizations go beyond the CVSS score alone:

• Our ethical hackers perform manual pentests that go beyond automated vulnerability scans, and discover attack paths that tools structurally miss.
• We translate technical findings into concrete priorities, so you know exactly which action has the greatest impact.
• Through our Continuous-Q program, we keep your security up to date throughout the year, not just on the day of the test.
• We provide independent advice, without dependency on software vendors or other suppliers.

Want to know how vulnerable your organization truly is and which risks deserve priority? Contact us for a no-obligation conversation.

Lees meer