Across enterprise estates in the UAE the same weaknesses keep surfacing, year after year, in organisations that are otherwise well run. They are not exotic. Almost none of them require a novel exploit. What they have in common is that each one sits in the gap between two teams, which is exactly where routine vulnerability assessment and penetration testing finds them and exactly why they survive the fix cycle. This article walks through the ten that appear most consistently, what each one actually costs when it is used, and the control change that closes it rather than deferring it to the next report. Our note on why hidden weaknesses survive scanning covers the discovery side.

Key Takeaways

• Nine of the ten most common findings are configuration and lifecycle failures rather than software defects, which means the fix is an ownership decision far more often than it is a patch.
• Exposure beats severity when you are prioritising. A medium-rated flaw on an internet-facing service that already appears in public exploitation catalogues outranks a high-rated flaw behind three authentication layers.
• Every recurring finding should be traced back to the process that produced it. Closing the instance without closing the process guarantees the same item returns in the next report.

Exposed Management Interfaces

The single most frequent finding is an administrative interface reachable from the public internet. Hypervisor consoles, network device managers, storage controllers and backup administration portals all appear regularly, usually because a firewall rule was opened for a migration and never closed afterwards.

The cost is immediate. These interfaces sit above the operating system, hold credentials for the whole estate below them, and are frequently excluded from the patch cycle because taking them offline disrupts everything. An attacker who reaches one does not need to move laterally; they are already at the top.

What makes the finding stubborn is that the exposure is usually correct at the moment it is created. A vendor needs remote access for a cutover weekend, a rule is written, the cutover succeeds and the ticket closes. Nothing in that sequence contains a step that removes the rule, and the change record shows an approved change rather than an error, so the next audit finds nothing to flag.

The fix is not a patch. It is a standing rule that management planes are reachable only from a jump network, plus a monthly external review that compares what is actually exposed against what the firewall change record says should be. Estates that adopt this see the finding disappear permanently rather than cyclically.

Two organisational details make the difference between a rule that holds and one that erodes. The first is that the review is run by someone outside the team that owns the firewall, so a temporary exception has to be defended rather than simply remembered. The second is that every exception carries an expiry date at the moment it is created, which turns cleanup from a discretionary task into a scheduled one.

Unmanaged Credentials in Application Configuration

Hard-coded database strings, service account passwords in deployment scripts and API keys in repository history remain among the highest-impact issues found during testing. They persist because rotating them requires coordination between a development team, an operations team and often a supplier, and nobody owns the sequence.

The consequence is that a single repository compromise becomes a data breach. Credentials in configuration are usually privileged, rarely expire and almost never appear in the access review because they belong to no person.

Repository history is the part most teams forget. Removing a key from the current file does nothing if the commit that introduced it is still reachable, and testers routinely recover working credentials from branches that were merged years earlier. Any remediation plan that does not include rotating the secret as well as deleting it has closed the report and not the risk.

Closing this properly means moving secrets into a managed vault, giving every service account a defined owner and expiry, and adding a repository scan to the build pipeline so that new instances fail the build rather than reaching production. It is a three-sprint project in most enterprises and it removes a whole category of finding.

Injection and Broken Access Control in Web Applications

Injection flaws and broken access control still dominate application findings, exactly as the widely used application risk list predicts. Injection is usually caught before release; broken access control is usually not, because it requires a tester to hold two accounts at once and try to reach one user's data with the other's session.

This is where dynamic testing earns its keep. A DAST run against a running application catches authorisation gaps that no static review will surface, because the flaw lives in runtime state rather than in the source. Enterprises running website penetration testing on every major release consistently find fewer of these reaching production.

The structural fix is to make authorisation a shared library rather than a per-endpoint decision. Where each controller implements its own check, the checks drift, and the drift is what testers find.

There is a testing implication as well. Authorisation testing needs at least two accounts at different privilege levels, plus a tenant boundary if the application is multi-tenant, and those accounts have to be provisioned before the engagement window opens. Assessments that start with a single read-only account will report clean on exactly the category most likely to be exploited.

Unpatched Edge Devices and Legacy Protocols

Perimeter appliances, remote access gateways and file transfer products account for a disproportionate share of real intrusions relative to how few devices they represent. They are internet-facing by design, they run vendor firmware on an unfamiliar update cycle, and they are often owned by a network team that does not receive the security patch feed.

Alongside them sit legacy protocols that should have been retired years ago: unauthenticated file shares, deprecated transport encryption, and management protocols with default community strings. Each is individually low severity and collectively decisive, because together they turn a single foothold into full estate access.

Ownership is usually the root problem rather than diligence. Edge appliances sit between the network and security functions, and vendor advisories arrive by email to an individual rather than into the patch pipeline. Naming a single accountable owner per appliance class, and routing its advisories into the same queue as server patching, closes more of this category than any tooling change.

Prioritisation here should follow evidence of real-world use rather than raw score. Cross-referencing your findings against the catalogue of vulnerabilities known to be actively exploited is the fastest way to separate the items that need an emergency change window from those that can wait for the quarterly cycle.

Cloud Storage, Identity and Backup Misconfiguration

As estates move, the finding profile moves with them. Publicly readable object storage, over-permissive role assumptions, unrestricted network security groups and disabled logging now appear in almost every cloud assessment. None of these is a vulnerability in the software; all of them are decisions.

Backup configuration deserves separate mention because it is the control that decides whether a ransomware event is a bad week or an existential one. Assessments regularly find backups written to storage reachable with the same credentials that run production, which means a single compromise takes both.

Identity misconfiguration in cloud estates has its own pattern. Roles are created broadly during a migration so that nothing blocks, with an intention to tighten them afterwards that rarely survives the next project. Because the permissions work, no incident forces a review, and the estate accumulates standing privilege that no single person can now describe. Access analysers that report which permissions were actually used over ninety days turn that from an argument into a data exercise.

Logging deserves the same scrutiny. Assessments frequently find that control plane audit logs are enabled but retained for days rather than months, which means that by the time an intrusion is discovered the evidence needed to scope it has already aged out. Retention is cheap relative to the cost of an investigation that cannot establish what was accessed.

The remediation pattern is consistent: separate the backup identity plane from the production one, enable immutability where the platform offers it, and test a restore rather than a backup job status. Infrastructure choices matter here too, and our note on data centre architecture and efficiency covers the platform side of the same problem.

Identity Gaps, Shadow Assets and What to Do Next

Rounding out the list are three findings that share a root cause. Accounts that survive an employee's departure. Multi-factor exceptions granted for a migration and never revoked. And assets nobody knew existed, usually spun up by a project team and never entered into the register.

All three are lifecycle failures rather than technical ones, and all three are invisible to scanning tools that only test what they are pointed at. Regular vulnerability assessment and penetration testing finds them precisely because a tester enumerates what is reachable rather than what is documented.

Shadow assets are the hardest of the three to close permanently, because the behaviour that creates them is usually reasonable. A project team needs an environment quickly and the formal route takes three weeks. The durable answer is to make the sanctioned route faster and to reconcile cloud billing data against the asset register monthly, since anything running is being paid for and therefore visible somewhere.

For prioritisation, exposure and exploitability should outrank raw severity. Scoring systems that estimate the probability of exploitation, such as the exploit prediction scoring system, give a more useful ordering than severity alone when your remediation capacity is finite, which it always is.

The practical next step is to take your last report and sort it not by severity but by the process that produced each finding. Items that trace to the same process get one fix. If you would like a second pair of eyes on that exercise, our assessment team can review the last report you received and map the findings back to their sources. You can also see how our wider security practice is organised and where testing sits within it, or read our note on building a proactive rather than reactive programme.