Unauthorized access refers to any successful or attempted access to systems, services, or data without the proper permissions. These incidents can result from misconfigurations, credential theft, or flaws in identity and access management—and often go unnoticed without proper detection mechanisms in place.
There are three types of unauthorized access:
Unauthorized user access involves external attackers or insiders making access attempts through existing user accounts.
Unauthorized application or system access is the exploitation of service accounts that have more permissions than they need.
Unauthorized data access happens when attackers bypass data loss prevention (DLP) measures or read sensitive data from object storage.
What are the common causes of unauthorized access in the cloud?
Publicly accessible resources
If a system doesn’t have any access restrictions, everyone can waltz right in. This is one of the most common causes of unauthorized access: After all, public access is often enabled for development purposes and then forgotten. Later, a resource might be used for sensitive data, exposing that sensitive information to the public.
Unauthorized access can be the result of…
Public S3 buckets: Since S3 supports direct access via HTTP, an engineer might facilitate easy integration by omitting access controls for a bucket. The problem? The moment someone learns the bucket's address, they can access all data in it.
Unsecured databases: Usually, there’s no direct access from a user-operated client to a database; only application servers interact with it. Here’s where the false sense of security comes in: When databases are on private VPC networks, it can lead to the assumption that strong auth mechanisms aren’t required. But if the network configuration changes, the insecure database may become publicly accessible.
Exposed API endpoints: Just like insecure databases, API endpoints are a frequent target of attacks.
Public VM instances: Starting an instance and assigning it a public IP address is a very convenient process, especially when you’re looking to keep development moving fast. Still, if they’re not configured correctly, these instances can become an open door for lateral movement attacks.
Misconfigured IAM policies
Because IAM security policies directly control access to cloud resources and require explicit information to be created securely, they’re a major cause of unauthorized access.
Examples of IAM misconfigurations are…
Wildcard resource permissions: It’s easier to write one asterisk than to list all resources in an IAM policy, but wildcard resource permissions can allow access to way more resources than intended.
Unrestricted service actions: As with resource permissions, IAM policies allow the use of wildcards that may allow more actions than a task requires.
Missing condition statements: Without a timeframe, a policy can be valid for too long. If this kind of policy leaks, then an attacker has more time to use it.
Exposed credentials or tokens
Putting API keys and credentials into secure storage often takes extra effort, so developers sometimes hardcode them, creating a prime route for unauthorized access.
Credential access attacks take advantage of…
Hardcoded API keys: When an API key or token is written directly into the code, everyone with access to that code can use the key.
Leaked CI/CD tokens: While CI/CD tokens don’t provide direct access to a production system, they may allow an attacker to access code repositories indirectly or inject malware into the code that the pipeline will deploy.
Unprotected config files: The purpose of config files is to avoid hardcoded information and make software more flexible. But since they are commonly checked into version control, config files can be exposed to similar risks as hardcoded secrets.
Compromised identities
Even if all permissions are assigned correctly, it’s still possible for someone to get access to an account or role.
Here’s how:
Phishing attacks: Users are contacted by an impostor who attempts to convince them to disclose their credentials
Session hijacking: Attackers install malware on a user's computer to hijack session cookies after the user has completed multi-factor authentication (MFA)
OAuth token theft: Similar to session hijacking and phishing, an attacker might coerce a user to interact with a fake website or install malware to steal their OAuth tokens
Lack of context-aware controls
As cloud resources grow, you need access controls that scale. But without context awareness, scaling up can lead to over-permissioning.
Types of access control without context awareness include…
Group-based access without validation: Assigning a permission based on a group without checking for anomalies in login location or device
Missing attribute checks: Ignoring attributes like access time or session duration when granting access
Inconsistent permission boundaries: Multiple access methods to a single resource may have different permissions
Inadequate access reviews
Securing a cloud environment requires constant vigilance. Otherwise, outdated access controls can become a growing problem over time.
Inadequate access reviews can create issues like…
Orphaned accounts: If someone leaves a company and their user account isn’t disabled or removed, it becomes a vulnerability risk.
Unused roles: If a service is retired but the role it supports is not, someone might reuse it, creating problems later.
Non-expiring credentials: Every day a token is valid, the risk of exposure increases.
Stale permissions: This is when the tasks performed by a user or service have changed over time, but the associated permissions have not. As a result, the user/service may have access to resources that are no longer required.
What are the risks of unauthorized access?
The main risks of unauthorized access are data leakage, data exfiltration, and service disruption:
People may (intentionally or unintentionally) gain access to sensitive information stored in your cloud environment, including private user data and trade secrets.
Data leaks can compromise your compliance status, putting you at a competitive disadvantage or exposing your users’ information to threat actors.
Unauthorized access also makes you vulnerable to service disruption and sabotage. Attackers can leverage lateral movement attacks (e.g., exploiting CI/CD access to deploy malware) and privilege escalation to compromise your services or run software (e.g., cryptocurrency miners or Tor nodes).
Who is responsible for preventing unauthorized access in the cloud?
In cloud environments, access control is a shared responsibility. Cloud providers secure the infrastructure, but customers are responsible for configuring IAM policies, securing credentials, and reviewing permissions. Misconfigurations on the customer side are one of the most common causes of unauthorized access incidents.
Real-world examples of unauthorized access
Capital One (2019): An attacker exploited a misconfigured AWS IAM role to gain access to sensitive data stored in S3 buckets.
Uber (2022): An attacker used stolen credentials obtained via social engineering to access internal systems and cloud resources.
Microsoft Exchange (2021): Threat actors gained unauthorized access via unpatched vulnerabilities and exfiltrated email data.
What is CIEM? Cloud Infrastructure Entitlement Management Use-Cases, Challenges, and Benefits
Read moreHow do you detect unauthorized access?
Luckily, several techniques can help you detect unauthorized access:
Cloud audit log analysis is the process of filtering the audit logs of a service (such as AWS CloudTrail) for suspicious logins, API calls, or data access attempts. This provides clues about resources and accounts that may be at risk—or are already compromised—and require mitigation.
VPC flow logs and network monitoring allow you to observe traffic metadata—such as IP addresses and data volumes—between your cloud resources. While they don’t reveal payloads, they can signal potential lateral movement or data exfiltration attempts based on anomalies in data size, direction, or frequency.
With behavioral anomaly detection (e.g., Wiz Defend), you check if user and service behavior changes over time and verify whether those changes are valid or not.
Finally, you can use access pattern correlation to link access with roles, workloads, and assets to find out if a resource interaction is risky or touches sensitive data in your environment.
How to prevent unauthorized access in the cloud
A security explainer wouldn’t be complete without offering actionable information. Here some best practices to help you maintain access control:
Enforce the principle of least privilege in all policies. Start by auditing your IAM roles, policies, and trust relationships, and then tighten them according to the actual needs of your workloads and users.
Ensure that all credentials are stored in an encrypted vault and are regularly rotated to maintain security. This way, a breach of one system might not leak secrets, and even if it does, they won’t be useful to an attacker for long.
Implement MFA wherever supported, especially for user accounts with sensitive access. While MFA isn’t a silver bullet—particularly for service accounts or in cases of session hijacking—it significantly reduces the likelihood of credential-based unauthorized access.
Adopt policy as code (PaC) for access enforcement and to minimize the human errors that manual policy creation can introduce.
Continuously monitor your effective permissions (i.e., the actual permissions users get after a policy is evaluated) with cloud infrastructure entitlement management (CIEM) tools. This way, you don’t have to hope your declared roles do what you think; you can see them in action.
Monitor resources exposed to the public internet, such as storage buckets, compute instances, and API endpoints, to quickly identify suspicious traffic.
How does Wiz help prevent and detect unauthorized access?
Wiz Defend provides you with all the tools and services you need to understand your identity and access controls. Wiz Defend detects lateral movement, suspicious behavior, and unauthorized access at runtime using flow logs and identity context—and also correlates access risk with workload data and exposure in the unified Wiz Security Graph.
Wiz also correlates identity access with data sensitivity, showing you when overly permissive roles have access to highly sensitive data such as PII, secrets, or IP. This context-aware approach helps you prioritize what matters most—stopping real attack paths before they’re exploited. Unlike legacy solutions that operate in silos or require heavy agent deployment, Wiz provides full access context by combining IAM data, resource configuration, runtime signals, and data sensitivity into a unified security graph—no agents or manual stitching required.
But Wiz’s access control protections don’t stop there. Check out Wiz’s CIEM capabilities, which surface over-permissioned identities, exposed roles, and privilege escalation paths. Better yet? Agentless scanning enables you to gain insights without the need for time-consuming installations—getting you the valuable information you need quickly.
Want to see how your cloud identities and sensitive data are exposed? Request a Wiz demo to get a personalized risk assessment based on real attack paths in your environment.