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

Which Changes in Your IT Environment Can Create New Attack Paths?

Geplaatst op: 27 September 2026

Every change in your IT environment can create new attack paths: combinations of vulnerabilities, misconfigurations, identities, and permissions that an attacker can chain together to gain access to systems or data. The larger and faster the changes, the greater the chance that temporary blind spots emerge that fall outside the view of existing security measures. The questions below help you understand which changes introduce the most risk and how to proactively limit that risk.

Which IT changes increase the likelihood of a successful attack?

IT changes that increase the likelihood of a successful attack are typically changes that introduce new entry points, expand existing permissions, or reduce the visibility of your security. Think of cloud migrations, new vendor integrations, changes to account permissions, and the rollout of new applications. Each of these changes shifts the attack surface, often without security controls being adjusted immediately.

What many organizations underestimate is that an attacker is not looking for one big mistake. An attacker looks at the combination of small weaknesses that together form a working path. A new cloud resource with an overly permissive configuration may not be critical on its own. But combined with an account that has too many privileges and a vendor with direct network access, it suddenly becomes a realistic route to sensitive systems.

The most high-risk IT changes are:

• Expansion of cloud infrastructure without corresponding reconfiguration of access policies
• New user accounts or service accounts with overly broad permissions
• Integrations with external parties that are granted direct network or data access
• Changes to applications that bypass or modify existing security controls
• Adjustments to firewall rules or network segmentation that accidentally open up too much

The core of the problem is that security is often configured at a specific point in time, while the environment continues to change afterward. A manual pentest as a baseline provides insight into the situation at that moment, but the day after the test the environment begins to shift again.

How does an attack path emerge after a cloud migration?

After a cloud migration, new attack paths emerge because cloud resources are configured differently by default than on-premises systems, and because the combination of identities, roles, and permissions in the cloud is far more complex and dynamic. Misconfigurations in cloud storage, overly permissive IAM permissions, and insufficient network segmentation are the most common causes.

During a cloud migration, systems and data are moved to an environment where the rules of the game are fundamentally different. On-premises, you had physical and logical boundaries that were relatively stable. In the cloud, resources are quickly created, permissions easily expanded, and connections effortlessly established — which also means mistakes are made quickly and not always noticed.

Concrete examples of how attack paths emerge after a migration:

• A storage bucket that was accidentally made publicly accessible during the migration
• Service accounts with administrator privileges that were created for temporary migration work and never removed
• Insufficient separation between production and test environments, allowing an attacker to pivot from the test environment into production
• Legacy systems that were temporarily connected to the cloud, thereby forming a bridge between old and new

An attacker only needs to find one of these weaknesses to gain an initial foothold. From that starting point, they can then move laterally through the environment, looking for privileges that take them further. That is precisely why cloud migrations should always be accompanied by a thorough security evaluation — not only at the start but also in the weeks and months that follow.

Why are new vendor integrations a security risk?

New vendor integrations are a security risk because they grant an external party access to your systems, networks, or data, while you have limited control over the security posture of that party. An attacker who compromises the vendor automatically gains a path into your environment.

This type of attack, also known as a supply chain attack, is one of the most effective methods for attackers. Instead of directly attacking a well-secured organisation, they target a smaller or less well-secured vendor with access to that organisation. The connection between vendor and client thus becomes the weakest link in the chain.

What makes this extra dangerous is that the access vendors receive often extends further than strictly necessary. Think of:

• Administrators from external parties with permanent access via VPN or remote desktop
• API integrations that share more data than necessary for the specific function
• Shared accounts or credentials that are not individual and therefore cannot be properly monitored
• Vendors that have access to multiple client environments simultaneously

For Managed Service Providers, this risk is especially acute. An MSP typically manages the IT environments of multiple clients simultaneously, which means that compromising one MSP can directly provide access to all those client environments. This makes MSPs an attractive target for attackers who want to cause maximum damage with a single breach. More about how these types of scenarios are tested in practice can be found on the page about red teaming.

How quickly can attackers exploit a new attack path?

Attackers can exploit a new attack path within days or even hours, depending on the visibility of the vulnerability and the motivation of the attacker. Publicly visible misconfigurations, such as a publicly accessible cloud resource, are often discovered by attackers’ automated scanners within 24 hours.

This is precisely why the traditional approach of one pentest per year is so problematic. An annual pentest is a snapshot: it shows what the security looks like on the day of the test. But the day after the test, the environment begins to change again. Applications are updated, accounts are added, permissions are adjusted, new cloud resources are created. Every change can introduce a new attack path that goes undetected for months until the next test.

Cybercriminals work 365 days a year. They actively track new vulnerabilities, continuously scan the internet for misconfigurations, and adapt their techniques as soon as new opportunities arise. An organisation that only has insight into its attack surface on the day of the test is effectively blind to new risks for the remaining 364 days.

The speed at which an attack path can be exploited depends on:

• The visibility of the vulnerability (externally visible versus internal)
• The value of the data or systems reachable via the path
• Whether the attacker has previously had access and is waiting for a new opening
• The complexity of the exploitation (some paths require more steps and time)

How do you detect new attack paths before attackers do?

You detect new attack paths by continuously monitoring your environment for changes that affect the attack surface, and by regularly testing whether those changes have created new attack opportunities. This requires a combination of technical monitoring, periodic manual tests, and a clear overview of who has access to what.

The first step is visibility. You cannot defend what you cannot see. That means you need an up-to-date picture of your IT environment: which systems are running, which accounts exist, what permissions those accounts have, and which connections exist with external parties. For many organisations, this overview is already a challenge, especially when the environment is growing quickly or changing regularly.

Practical measures to detect new attack paths early:

1. Conduct a thorough baseline pentest as a starting point, so you know what the current attack paths are
2. Establish change management processes in which security implications are weighed with every IT change
3. Actively monitor identities and permissions for anomalies, such as accounts that suddenly have more permissions than usual
4. Test after significant changes, not just once a year but whenever the environment changes substantially
5. Think like an attacker: with every change, ask yourself how an attacker could exploit it in combination with existing weaknesses

The difference between a vulnerability scan and a real attack path analysis is crucial here. An automated scan finds individual vulnerabilities. But an attacker combines those vulnerabilities with misconfigurations, identities, and permissions into a working path. Only by testing the way a real attacker tests do you gain insight into the actual risks. More background on how this type of research is conducted can be found on the page about cyber research.

Continuous insight also begins with a solid understanding of compliance and policy around access management and change management. A solid compliance and policy framework helps you to structurally factor in security implications when making IT decisions.

How Q-Cyber helps map new attack paths

We help organisations detect new attack paths before attackers do, by combining what an automated scan cannot: thinking like a real attacker. Our approach is concrete and pragmatic:

• Baseline pentest: we start with a thorough manual pentest that not only exposes individual vulnerabilities, but also the combinations of weaknesses that together form a working attack path
• Continuous insight via Continuous-Q®: after the baseline, our specialists continue to monitor changes in your environment, so that new attack paths are identified as soon as they emerge and not only at the next annual test
• Independent advice: we are not tied to software vendors or tooling, which means our advice is always in your best interest
• Technical and policy-based: we combine technical depth with advice on access management, permission structures, and security policy

Whether you have just completed a cloud migration, connected new vendors, or simply want to know whether your current security can withstand the way attackers operate today: get in touch and we will look together at the right first step. More about our approach can be found on the page about Continuous-Q®.

Lees meer

Why Are Known Vulnerabilities Only Part of the Security Risk?

Geplaatst op: 26 September 2026

Every week, dozens of new vulnerabilities appear in software systems. Security teams scan, patch, and report, yet organizations are still getting hacked. How is that possible? The answer has everything to do with a persistent misconception: that known vulnerabilities represent the greatest security risk. In reality, they are merely the tip of a much larger iceberg.

In this article, we explain step by step what a vulnerability actually is, why known vulnerabilities don’t come close to showing the full risk picture, and which risks organizations structurally overlook. By the end, it will be clear why a different approach to cybersecurity is necessary to truly protect yourself.

What is a vulnerability and how does it become ‘known’?

A vulnerability is a weakness in software, hardware, or a configuration that an attacker can exploit to gain unauthorized access or cause damage. Think of a flaw in a web server’s code that allows an attacker to read files not intended for them.

Vulnerabilities become ‘known’ through a standardized system: once a researcher or vendor discovers and publishes a vulnerability, it receives a CVE number (Common Vulnerabilities and Exposures). This number makes the vulnerability officially traceable. Security teams, scanners, and vendors can then respond with patches or workarounds.

The crucial point is that a vulnerability only becomes ‘known’ after someone has discovered, documented, and published it. That process takes time. And during that interim period, the vulnerability already exists — it just isn’t yet visible to defenders.

How known vulnerabilities are merely the tip of the iceberg

The CVE system is valuable, but it only covers what has already been discovered and published. Beneath it lies a much larger invisible portion, comparable to an iceberg: what you see at the surface is only a fraction of what actually exists.

Three categories together make up that hidden portion of risk:

• Zero-day vulnerabilities: vulnerabilities that are not yet publicly known and for which no patch exists. Attackers, particularly sophisticated groups, actively exploit these before vendors are even aware of them.
• Misconfigurations: incorrectly configured systems, cloud services, or access rights that have no official CVE number, but can still be exploited. A cloud storage container that is accidentally publicly accessible won’t appear on any patch list.
• Logical weaknesses in identities and permissions: an account with excessive privileges, a service account with access to critical systems, or a vendor with unnecessary administrative rights. These are not technical bugs, but structural risks that scanners systematically miss.

An attacker doesn’t necessarily need to exploit a known CVE. Sometimes a combination of a misconfiguration, an account with too many privileges, and a poorly secured vendor portal is enough to penetrate deep into a network — without a single vulnerability scanner raising the alarm. Read more about how attackers approach this on the page about red teaming.

Why organizations still focus primarily on known risks

If known vulnerabilities only represent part of the risk, why do so many organizations focus almost exclusively on them? The answer is understandable: known vulnerabilities are measurable, reportable, and manageable.

Vulnerability management tools generate clear lists with CVE numbers, priority scores, and patch recommendations. That provides a sense of control. Auditors accept it as evidence of active security management. And after resolving twenty vulnerabilities, an organization feels demonstrably safer — even if the actual attack surface has barely changed.

This is precisely the danger of false security: the feeling that you’re doing well, while the risks that truly matter remain out of sight. Misconfigurations, identity issues, and logical weaknesses are harder to quantify and fit less neatly into a dashboard. As a result, they are structurally underexposed — not because they are less dangerous, but because they are less visible.

Which risks outside the patch list are most frequently exploited

Real attackers don’t think in CVE numbers. They think in attack paths: which combination of weaknesses will get me to my target as quickly as possible? And those paths rarely run through the most obvious known vulnerability.

The risks most frequently exploited but falling outside the patch list are:

• Identity and access issues: accounts with excessive privileges, weak passwords, reused credentials, or service accounts without monitoring.
• Cloud misconfigurations: incorrectly configured access controls, unsecured APIs, or publicly accessible storage buckets.
• Supply chain access: vendors and managed service providers with access to systems that are themselves insufficiently secured.
• Human behavior: employees who open phishing emails, share login credentials, or take shortcuts in security procedures.

An attacker who compromises an MSP instantly gains access to all of that MSP’s clients. That’s not a technical exploit — it’s a logical weakness in the structure of trust relationships. No standard vulnerability scan maps this type of risk.

Continuous testing as a response to a moving target

Building on everything explained above, one conclusion becomes unavoidable: a snapshot is insufficient to manage a dynamic risk. Your environment changes constantly. New applications are deployed, accounts are created, permissions are modified, cloud resources come and go. Every change can open a new attack path.

An annual pentest provides insight on a single day. But what happens after that remains out of sight. Cybercriminals develop new techniques throughout the year and continuously explore new attack paths. A traditional pentest is therefore comparable to a photograph of a moving target: accurate at the moment of capture, but quickly outdated.

The alternative is an approach where testing is not a one-time activity, but an ongoing process. It starts with a thorough baseline pentest that uncovers not only technical vulnerabilities, but also misconfigurations, identity risks, and logical weaknesses in attack paths. Changes in the environment are then actively tracked, so new risks are identified as soon as they arise — not only at the next annual test. Read more about this approach on the page about Continuous-Q®.

How Q-Cyber helps with vulnerability management

Q-Cyber helps organizations look beyond the patch list. Our approach combines technical depth with reasoning like a real attacker, so that not only known vulnerabilities come into view, but the full attack surface.

What we concretely offer:

• Manual pentests in which our ethical hackers actively search for attack paths that go beyond CVEs, including misconfigurations, identity risks, and logical weaknesses.
• Continuous-Q®, our ongoing testing program that continues to monitor the environment after the initial pentest and identifies new risks in a timely manner.
• Independent advice without ties to software vendors, so our recommendations are always in your best interest.
• Concrete reports with priorities and practical next steps, so you immediately know where action is needed.

Want to know how your organization truly stands — beyond the patch list? Get in touch with Q-Cyber and discover how we help you gain a complete and up-to-date picture of your security risk.

Lees meer

Why Are Misconfigurations Interesting to Hackers?

Geplaatst op: 25 September 2026

Imagine: an attacker spends months trying to gain access to a corporate network through advanced exploits, but fails. Then he discovers that a cloud environment was accidentally made publicly accessible by an administrator who had misconfigured a setting. Within an hour, he has access to sensitive data. This scenario is no exception. Misconfigurations are among the most common causes of successful cyberattacks worldwide.

In this article, you’ll learn step by step what misconfigurations are, how they occur, why they are so attractive to attackers, and what you can do to prevent them. We build the knowledge progressively: from the core of the concept to a practical approach to protecting your organization.

What is a misconfiguration in cybersecurity?

A misconfiguration is an incorrect or insecure setting in a system, application, network device, or cloud environment. Rather than a technical flaw in the software itself, it is an error in the way that software or system has been configured by an administrator or developer.

The difference from a traditional vulnerability (a so-called CVE) is important to understand. A CVE is a flaw in the code of software that the vendor must fix via a patch. A misconfiguration is an error in the configuration that the administrator has made or overlooked. The software works correctly from a technical standpoint, but the settings create a security gap.

A simple example: a database is secured by default with a password, but an administrator disables that security during a testing phase and forgets to re-enable it afterwards. The database itself has no bug, but the setting makes it vulnerable to anyone who knows where to look.

How do misconfigurations occur in practice?

Misconfigurations are rarely the result of negligence or ignorance alone. They arise from a combination of factors that exist in virtually every organization.

Complexity and speed

Modern IT environments consist of dozens, sometimes hundreds of systems and services. Cloud environments such as Azure or AWS contain thousands of configuration options. The more complex the environment, the greater the chance that a setting is incorrect somewhere. Especially when teams work under time pressure and need to deploy new systems quickly, security settings are sometimes deliberately or inadvertently skipped.

Default settings that are not adjusted

Many systems are delivered with default settings that prioritize convenience over security. Default passwords, open ports, broad access rights: these are settings designed to get a system up and running quickly, not to secure it optimally. If administrators do not actively adjust these defaults, they remain like an open door.

Changes without a security check

IT environments are constantly changing. Accounts are created, permissions adjusted, new applications deployed, and cloud resources added. Every change can introduce a new misconfiguration. Without a structured process to review changes for security implications, the gaps in security grow along with the environment.

Why are misconfigurations so attractive to attackers?

Attackers choose the path of least resistance. Misconfigurations are particularly attractive to them for three concrete reasons.

First, they are relatively easy to find. Many misconfigurations are visible through publicly accessible information, automated scans, or simply by attempting to connect to a system. An attacker doesn’t need to write a sophisticated exploit; they just need to look for what is already exposed.

Second, they raise no suspicion. An attack via a misconfiguration often looks like normal traffic to monitoring systems. There is no malicious code to trigger an antivirus program. The attacker uses a legitimate access route that happens to be left open by accident.

Third, they can be combined into an attack path. This is an insight central to how modern attackers operate: they don’t look at individual vulnerabilities, but at how multiple small weaknesses together form a route to sensitive systems. A misconfiguration in a cloud identity, combined with overly broad access rights and an incorrect firewall setting, can together lead to full access to critical data, while none of the three individually would be assessed as critical.

This principle, also known as attack path testing, shows why simply fixing individual findings is not enough to truly protect an organization.

Which systems and settings are most frequently misconfigured?

Certain categories of systems repeatedly appear as sources of misconfigurations. Knowing this helps you focus your attention on the areas where the risk is greatest.

• Cloud environments: Azure, AWS, and Google Cloud offer enormous flexibility, but also an enormous number of configuration options. Incorrectly configured access roles (RBAC), publicly accessible storage buckets, and overly broad managed identity permissions are classic examples.
• Firewalls and network devices: Unnecessary open ports, outdated rules, and insecure default settings on routers and switches regularly create access opportunities that should not exist.
• Identity and access management (IAM): Accounts with excessive privileges, inactive accounts that have not been removed, and weakly configured multi-factor authentication are vulnerabilities that attackers actively seek out.
• Web applications and APIs: Error messages that reveal too much technical information, missing security headers, and unsecured API endpoints are common misconfigurations in application layers.
• Collaboration tools and email platforms: Incorrectly configured Microsoft 365 or Google Workspace environments can lead to unwanted external access or data breaches.

How do you discover misconfigurations before a hacker does?

Building on the understanding of where misconfigurations originate and which systems are most vulnerable, the next step is to actively search for them. A fundamental principle applies here: you can only defend what you test.

Vulnerability scans as a starting point

Automated vulnerability scans can quickly map known misconfigurations and weak settings. They are valuable as a basic check, but have an important limitation: they find what is in their database, not what a creative attacker would discover. They see individual findings, not attack paths.

Manual pentests for the deeper layer

In a manual pentest, an ethical hacker thinks like a real attacker. He combines discovered misconfigurations with other weaknesses to assess whether a viable attack path exists. A misconfiguration that appears low-risk on its own can suddenly turn out to be critical in combination with another weakness. This level of insight is only achievable with human reasoning, not with automated tools.

Red teaming for the full picture

For organizations that want to go a step further, red teaming offers a realistic simulation of a complete attack. A red team attempts to gain access in every possible way, including via misconfigurations, social engineering, and supply chain weaknesses, to test whether an organization’s defenses hold up in practice.

Preventing misconfigurations with a structural approach

Discovering misconfigurations is valuable, but structurally preventing them is the ultimate goal. A one-time test provides insight at a single moment, while the environment may already change the next day. A sustainable approach therefore requires continuity.

Some concrete measures that contribute to a structural approach:

• Establish a baseline: Document the desired configuration of each system and use it as a reference point for future changes.
• Integrate security into change management: Every change in the IT environment, no matter how small, must be assessed for security implications before it is implemented.
• Limit permissions to what is necessary: Apply the principle of least privilege: grant accounts and systems only the permissions they actually need.
• Actively review default settings: Make it a fixed habit to review the default settings of new systems and services before they are put into use.
• Test continuously, not just once: Because environments are constantly changing, periodic or continuous testing is the only way to maintain up-to-date insight into the security status.

An annual test gives you a snapshot of a moving target. What you truly need is a continuous view of how your environment evolves and where new gaps emerge. Read more about how continuous testing works in practice on the Continuous-Q page.

How Q-Cyber helps with detecting misconfigurations

Misconfigurations are subtle, widespread, and change along with your environment. They require a partner who not only looks at individual findings, but understands how an attacker combines them into a working attack path. That is precisely what we focus on.

At Q-Cyber, we address misconfigurations with a layered approach:

• Manual pentests in which our ethical hackers think like real attackers and assess misconfigurations in the context of the full attack path, not as isolated findings.
• Red teaming for organizations that want to know whether their defenses hold up against a realistic, full attack simulation.
• Continuous-Q, our program for continuous insight, so you know where you stand not just on the day of the test, but throughout the entire year.
• Concrete reporting and advice with clear priorities, so you immediately know which misconfigurations pose the greatest risks and what to do about them.

Want to know which misconfigurations are present in your environment before an attacker finds them? Contact us and we’ll discuss which approach best fits your organization.

Lees meer