Cloud Security Glossary: CSPM to Workload Identity

Cloud security is full of acronyms that overlap, change meaning between providers and get stretched by product marketing, so teams often argue about words when they should be agreeing on controls. This glossary gives short, precise definitions of the terms practitioners meet when securing infrastructure, platform and container workloads in public cloud: posture and protection tools (CSPM, CWPP, CNAPP, CIEM, DSPM), identity and access constructs, guardrails, networking, encryption and logging. It is written for cloud security engineers, architects, auditors and risk teams who need a shared vocabulary across AWS, Azure and Google Cloud (providers are listed alphabetically throughout). Where a provider uses its own name for a common idea, the entry gives the general term first and the provider names after it. Identity, IAM and non-human identity terms are covered in more depth in the NHI and IAM Glossary.

A

Access key: A long-lived programmatic credential, made of a key ID and a secret, that lets a user or application sign API requests to a cloud provider. In AWS the term refers to IAM user access keys. Because access keys do not expire on their own, they are the credential most often found in public code repositories and the first thing attackers test. Prefer roles and short-lived credentials. See the AWS Access Keys Security Guide.
Account, subscription and project: The basic billing and isolation container in each provider: an AWS account, an Azure subscription (within a Microsoft Entra tenant), and a Google Cloud project (within an organisation). Each is a security boundary for permissions and quotas, and a common unit for scoping posture scores, logging and incident response. Splitting workloads across many of these containers limits blast radius.
Admission controller: A Kubernetes component that intercepts requests to the API server after authentication and authorisation, and can reject or modify objects before they are stored. Pod Security Admission and policy engines that run as validating or mutating webhooks are admission controllers. See the Kubernetes Admission Control Guide.
AssumeRole: The AWS Security Token Service (STS) operation that returns temporary credentials for an IAM role, provided the role's trust policy allows the caller. It is the mechanism behind cross-account access, federation and most service-to-service access in AWS. See the AWS STS and AssumeRole Guide.
Attack path: A chain of conditions that together let an attacker move from an entry point to a valuable asset: for example an internet-exposed virtual machine with a known vulnerability, whose attached role can read a storage bucket holding sensitive data. Posture tools increasingly rank findings by attack path rather than by single misconfiguration, because one path matters more than a hundred isolated findings.
Audit log (cloud): The provider's record of control plane activity: who called which API, from where, and with what result. The main services are AWS CloudTrail, the Azure Activity Log and Microsoft Entra logs, and Google Cloud Audit Logs. Data access events (reads of objects or secrets) are often off by default or billed separately, so confirm they are enabled for sensitive resources. See the Cloud Logging and Audit Trail Guide.
Availability zone: One or more physically separate data centres within a cloud region, with independent power and networking. Spreading workloads across zones protects against a single facility failure; spreading across regions protects against a regional outage. See the Cloud Region Outage Resilience guide.

B to C

Blast radius: The set of resources and data an attacker could reach if one identity, credential, workload or account were compromised. Reducing blast radius (separate accounts, narrow roles, network segmentation, per-workload keys) is usually more achievable than preventing every compromise. See Attack Surface vs Blast Radius.
Break-glass account: An emergency administrative account kept outside normal sign-in paths, used only when federation, MFA or the identity provider is unavailable. It needs strong credentials stored offline, alerting on every use, and regular testing. See the Break-Glass Account Guide.
Bucket policy: A resource-based policy attached to an object storage bucket that states which principals may perform which actions on it. A bucket policy that grants access to everyone, or to any authenticated user of the provider, is a classic cause of public data exposure. See the Amazon S3 Security Guide.
BYOK (bring your own key): A key management model in which the customer generates key material in its own system, often a hardware security module, and imports it into the provider's key service. The provider still uses the key to encrypt and decrypt, so BYOK gives control over key origin and deletion rather than isolation from the provider. See the Cloud Customer-Managed Keys and BYOK/HYOK Decision Guide.
CASB (cloud access security broker): A control point between users and cloud applications that gives visibility of SaaS use, enforces data and access policy, and detects risky sharing, either inline through a proxy or out of band through application APIs. CASB is now usually delivered as part of a security service edge (SSE) platform. See the CASB Guide.
CDR (cloud detection and response): Detection and investigation focused on cloud control plane logs, identity activity and workload runtime signals, rather than endpoint telemetry alone. Typical detections cover new access keys on dormant identities, disabled logging, mass snapshot sharing and unusual role assumption. See the Cloud Detection and Response Guide.
CIEM (cloud infrastructure entitlement management): Tooling and practice for discovering every human and non-human identity in cloud environments, calculating their effective permissions across policies, and removing permissions that are unused or excessive. CIEM answers the question "who can actually do what", which raw policy documents do not. See the Cloud PAM and CIEM Guide.
CIS Benchmarks: Consensus configuration baselines published by the Center for Internet Security, including Foundations Benchmarks for each major cloud provider and benchmarks for Kubernetes and managed Kubernetes services. Most posture tools ship CIS checks as a built-in standard. See the CIS Cloud Foundations Benchmarks Guide.
Cloud Controls Matrix (CCM): The Cloud Security Alliance's control framework for cloud computing, organised into domains and mapped to other standards. Providers use it, with the STAR registry, to publish their own control assessments. See the Cloud Security Alliance CCM and STAR Guide.
CNAPP (cloud-native application protection platform): A platform that combines posture management (CSPM), workload protection (CWPP), entitlement management (CIEM), and often infrastructure as code scanning, data posture and runtime detection, with a shared graph of resources so findings can be correlated into attack paths. See the CNAPP Guide.
Confidential computing: Protection of data in use by running workloads inside hardware-based trusted execution environments whose memory is encrypted and isolated from the host operating system and hypervisor, with remote attestation to prove what is running. See the Confidential Computing Guide.
Container escape: An attack in which a process inside a container gains access to the host node or other containers, usually through a privileged container, a mounted host path or socket, excessive Linux capabilities or a kernel flaw. Pod Security Standards at the Baseline or Restricted level block the most common configurations that enable it. See the Container Runtime Security Guide.
Container image: A packaged, layered file system and configuration from which containers are started. Image security covers base image choice, vulnerability scanning, removing secrets from layers, signing and admission rules that only allow approved registries. See the Container Image Security Guide.
Control plane: The management interface of a cloud service: the APIs and consoles used to create, configure and delete resources and to manage identities. Control plane access is the highest-value target in cloud attacks, because one privileged credential can change every resource. Contrast with data plane.
Cross-account access: Access granted to a principal in one account, subscription, project or tenant to resources in another, usually through a role trust relationship, a multi-tenant application consent or a resource policy. Each relationship is an external dependency that needs an owner and periodic review. See the Cross-Account and Cross-Tenant Access Guide.
CSPM (cloud security posture management): Continuous assessment of cloud resource configuration against security baselines and compliance standards, with findings, prioritisation and sometimes automated remediation. Provider-native examples are AWS Security Hub, Microsoft Defender for Cloud and Google Cloud Security Command Center. See the Cloud Security Posture Management (CSPM) Guide.
Customer-managed key (CMK): An encryption key created and controlled by the customer inside the provider's key management service, as opposed to a provider-managed default key. A CMK lets the customer set the key policy, rotation, logging of key use and disablement. See the Envelope Encryption and KMS Integration Patterns Guide.
CWPP (cloud workload protection platform): Protection for the workloads themselves (virtual machines, containers and serverless functions): vulnerability assessment, runtime threat detection, file integrity and application control. CSPM looks at how resources are configured; CWPP looks at what runs inside them. See CWPP vs CSPM.

D to H

Data perimeter: A set of preventive guardrails ensuring that only trusted identities access trusted resources from expected networks. In AWS it is built from service control policies, resource control policies, resource policies and VPC endpoint policies; Azure and Google Cloud reach similar outcomes with Azure Policy, private endpoints, and organisation policies with VPC Service Controls. See the Cloud Data Perimeter Guide.
Data plane: The operations that act on the content of a resource rather than its configuration: reading objects, querying a database, retrieving a secret value. Data plane permissions and logs are often managed separately from control plane ones, so a role that cannot change a database may still read every row.
DSPM (data security posture management): Discovery and classification of sensitive data across cloud storage, databases and SaaS, combined with analysis of who and what can reach it and how it is protected. DSPM starts from the data, where CSPM starts from the resource. See the Data Security Posture Management (DSPM) guide.
Drift (configuration drift): Divergence between the configuration declared in code or a baseline and the configuration actually deployed, usually caused by manual console changes. Drift breaks the assumption that a reviewed template describes production. See the Configuration Drift and Baseline Enforcement Guide.
Egress filtering: Restricting outbound network traffic from workloads to approved destinations, through firewalls, proxies, DNS filtering or private endpoints. It limits data exfiltration and the use of stolen credentials from inside the environment to attacker infrastructure. See Cloud Egress Filtering.
Encryption at rest: Encryption of stored data on disks, object storage, databases and backups. Most cloud services now encrypt at rest by default with provider-managed keys; the security decisions are who controls the key, who can use it, and whether key use is logged. See Encryption at Rest vs In Transit vs In Use.
Encryption in transit: Protection of data moving across networks, normally with TLS, including traffic between services inside the provider's network. Policies that deny requests not made over TLS are a common posture check for storage services.
Envelope encryption: The pattern in which data is encrypted with a data key, and the data key is itself encrypted with a key encryption key held in a key management service. It allows large volumes of data to be encrypted locally while the root key never leaves the KMS or HSM. See the Envelope Encryption and KMS Integration Patterns Guide.
External ID: A value that a third party must supply when assuming a role in a customer's AWS account, set as a condition in the role's trust policy. It defends against the confused deputy problem, where a vendor serving many customers could be tricked into acting on the wrong customer's account. See the Cross-Account and Cross-Tenant Access Guide.
FedRAMP: The United States government programme that authorises cloud services for federal agency use, based on NIST SP 800-53 control baselines. A FedRAMP authorisation is often used as evidence of control maturity outside government too. See the FedRAMP Guide.
Federated identity credential: A Microsoft Entra object, set on an app registration or a user-assigned managed identity, that tells Entra ID to trust tokens from an external identity provider when the token's issuer, subject and audience match the configured values exactly. It is the building block of workload identity federation in Azure. See the Azure Managed Identities Security Guide.
Guardrail: A control applied at the organisation level that holds for every account, subscription or project beneath it, whatever local administrators do. Preventive guardrails block an action (service control policies, Azure Policy deny effects, organisation policy constraints); detective guardrails report it. See the Cloud Landing Zone Security Guide.
Hardware security module (HSM): A tamper-resistant device that generates, stores and uses cryptographic keys so that key material never leaves it in plain form. Cloud providers offer both multi-tenant key services backed by HSMs and dedicated single-tenant HSMs. See the HSM Deployment and Operations Guide.
HYOK (hold your own key): A model in which the key that protects cloud data stays in a key manager outside the provider, which the cloud service must call for each cryptographic operation. It gives the customer the ability to cut off access, at the cost of availability and latency dependence on the external key manager. See the BYOK, HYOK and External Key Management Guide.

I to K

IaaS, PaaS and SaaS: The three service models in the NIST definition of cloud computing (SP 800-145): infrastructure as a service (the customer manages operating systems and up), platform as a service (the customer manages applications and data on a managed runtime), and software as a service (the customer consumes an application and manages its data, users and configuration). The model decides where the shared responsibility line falls.
Infrastructure as code (IaC): Defining cloud resources in version-controlled templates (for example Terraform, AWS CloudFormation, Azure Bicep) that are deployed by a pipeline. IaC makes configuration reviewable and repeatable, and moves many posture checks to before deployment. See the Infrastructure as Code Security Guide.
IaC scanning: Static analysis of infrastructure templates against security rules before they are applied, so a public bucket or wildcard role is caught in a pull request rather than in production. See the Checkov and IaC Scanners Guide.
Identity-based policy: A permission policy attached to a user, group or role that states what that principal may do. It is evaluated together with resource-based policies, permission boundaries, session policies and organisation guardrails to produce the effective permission. See the AWS IAM Policies and Roles Guide.
IMDS (instance metadata service): A link-local endpoint (169.254.169.254 on AWS, Azure and Google Cloud) from which a virtual machine reads its own configuration and, where a role or identity is attached, temporary credentials. Server-side request forgery against IMDS is a well-known route to cloud credential theft, recorded in MITRE ATT&CK as T1552.005 Cloud Instance Metadata API. See the Cloud Instance Metadata Services Compared Guide.
IMDSv2: The session-oriented version of the AWS instance metadata service. A client must first obtain a token with a PUT request and present it on each GET; PUT requests carrying an X-Forwarded-For header are rejected, and the default hop limit of 1 stops the token reaching most forwarded traffic. Setting HttpTokens to required turns IMDSv1 off for an instance.
Immutable infrastructure: An operating model where servers and containers are never changed in place: a new version is built from code and the old one is replaced. It makes drift and persistent tampering easier to detect, because any change to a running instance is unexpected. See the Immutable Infrastructure Security Guide.
Key management service (KMS): A managed service for creating, storing, rotating and controlling the use of encryption keys, integrated with other cloud services: AWS KMS, Azure Key Vault and Google Cloud KMS. Key policies and key usage logs are central to proving who can decrypt data. See the AWS KMS Security Guide, the Azure Key Vault Security Guide and the Cloud KMS and Cloud HSM Guide.
Kubernetes RBAC: The Kubernetes authorisation model in which Roles and ClusterRoles list allowed verbs on resources, and RoleBindings and ClusterRoleBindings grant them to users, groups or service accounts. Bindings to cluster-admin and wildcard rules are the usual audit targets. See the Kubernetes RBAC Guide.
Kubernetes service account: The identity a pod uses to call the Kubernetes API and, through workload identity features in managed services, cloud APIs. Current Kubernetes versions issue short-lived, audience-bound projected tokens rather than long-lived secret-based tokens. See the Kubernetes Service Account Token Guide.

L to N

Landing zone: A pre-built, multi-account cloud foundation with identity, logging, networking and guardrails already in place, into which new workloads are deployed. Examples include AWS Control Tower, Azure landing zones and the Google Cloud enterprise foundations blueprint. See the Cloud Landing Zone Security Guide.
Least privilege: Granting each identity only the permissions needed for its task, for only as long as needed. In cloud it is measured by comparing granted permissions with permissions actually used, which unused access analysis in each provider supports. NIST SP 800-53 control AC-6 sets the requirement. See the Least Privilege Techniques Guide.
Log sink: A routing rule that exports logs from a project, folder or organisation to a destination such as a storage bucket, a data warehouse or a message stream. Organisation-level sinks into a separate, locked-down logging project are the standard pattern in Google Cloud. See the Google Cloud Audit Logs and Log Sinks Guide.
Managed identity: An Azure identity for a resource, either system-assigned (tied to one resource's lifecycle) or user-assigned (a standalone resource that can be attached to many), for which the platform issues and rotates credentials automatically. See the Azure Managed Identities Security Guide.
Management hierarchy: The tree used to apply policy and permissions to groups of accounts: organisational units in AWS Organizations, management groups in Azure, and folders under the organisation node in Google Cloud. Designing it around security boundaries (production, non-production, sandbox, security tooling) makes guardrails simple. See the Azure Policy and Management Groups Guide.
Microsegmentation: Fine-grained network policy that limits which workloads may talk to each other, often down to individual services or pods, instead of trusting everything within a subnet. In cloud it is implemented with security groups, network security groups, firewall rules and Kubernetes network policies. See the Kubernetes Network Policy Guide.
Misconfiguration: A setting that leaves a resource less protected than intended: public storage, open management ports, disabled logging, unencrypted snapshots, wildcard permissions. Misconfiguration is the condition CSPM exists to find. See the Cloud Misconfiguration Guide.
Network security group and security group: Stateful, allow-list firewall rules applied to network interfaces or subnets: security groups in AWS, network security groups in Azure, and VPC firewall rules in Google Cloud. A rule allowing 0.0.0.0/0 to ports 22 or 3389 is one of the most common high-severity posture findings. See the Cloud Network Security Guide.
Non-human identity (NHI): Any identity used by software rather than a person: roles, service accounts, service principals, managed identities, access keys, tokens and AI agent identities. In most cloud estates NHIs far outnumber human users and hold much of the standing privilege. See the Cloud Workload Identity Guide.

O to P

OIDC federation (for pipelines): Letting a CI/CD system exchange its own signed OpenID Connect token for short-lived cloud credentials, instead of storing static keys in pipeline secrets. Trust conditions must pin the repository, branch or environment claim, or any workflow from the same identity provider could assume the role. See the GitHub Actions OIDC Federation Hardening Guide.
Organisation policy (Google Cloud): Constraints set on the Google Cloud resource hierarchy that restrict how resources may be configured, for example blocking service account key creation, restricting public IP addresses or limiting resource locations. They are inherited down the hierarchy. See the Google Cloud Organization Policy Guide.
Permissions boundary: An AWS managed policy set as the maximum permissions an IAM user or role can have, used to let teams create their own roles without being able to exceed a ceiling. Like a service control policy, a boundary grants nothing on its own; the action must also be allowed by an identity-based policy.
Pod Security Admission: The built-in Kubernetes admission controller that applies the Pod Security Standards (Privileged, Baseline and Restricted) per namespace, in enforce, audit or warn mode, set by namespace labels. It replaced PodSecurityPolicy. See PodSecurityPolicy to Pod Security Admission.
Policy as code: Writing security and compliance rules in machine-readable form, stored in version control and evaluated automatically in pipelines, admission controllers or cloud policy services. It turns a written standard into a test that runs on every change. See the IaC identity policy checks guide.
Principal: The entity that a cloud policy grants or denies access to: a user, role, group, service account, service principal, managed identity, or a federated identity. Reading a policy correctly starts with knowing exactly which principals it names, including wildcards.
Private endpoint: A network interface inside a customer's virtual network that gives private access to a provider service or partner service, so traffic does not cross the internet: AWS PrivateLink interface endpoints, Azure Private Endpoint and Google Cloud Private Service Connect. See the Cloud Private Connectivity Guide.
Public exposure: A resource reachable from the internet, or by any identity outside the organisation, through network rules, public IP addresses, anonymous access settings or shareable links. Posture tools treat it as a multiplier on other findings, since a vulnerability on an exposed host is far more urgent. See the Cloud Storage Exposure Playbook.

R to S

Resource-based policy: A permission policy attached to a resource (a bucket, key, queue, function or secret) that states which principals, including those in other accounts, may act on it. Resource policies are how most unintended external access happens, which is what external access analysis looks for. See the IAM Access Analyzer Guide.
Resource control policy (RCP): An AWS Organizations policy type that sets the maximum permissions available on resources in member accounts, whoever the caller is. Together with service control policies, it is a building block of an AWS data perimeter. See the AWS Resource Control Policies and Data Perimeter Guide.
Root user: The identity created with an AWS account that has full access to it. It should have MFA, no access keys, and be used only for the few tasks that require it; in AWS Organizations, member account root credentials can be centrally managed. See the AWS Root Account Compromise Playbook.
SAS token: An Azure Storage shared access signature: a signed URL that grants scoped, time-limited access to storage resources. Account-level SAS tokens with long expiry and broad permissions behave like a password that cannot be individually revoked, unless issued under a stored access policy or as a user delegation SAS. See the Azure SAS Tokens Security Guide.
Secrets manager: A service that stores credentials such as database passwords and API keys, controls access to them, logs retrieval and supports rotation: AWS Secrets Manager, Azure Key Vault secrets and Google Cloud Secret Manager. See the Cloud Secrets Managers Guide.
Secure score: A posture percentage or index produced by a provider's security service. AWS Security Hub reports a standard score as passed controls divided by passed, failed and unknown controls; Microsoft Defender for Cloud has a classic secure score built from control points per resource and a newer risk-based cloud secure score from 0 to 100. Scores from different tools are not comparable. See the Cloud Security Metrics guide.
Serverless: Running code or managed services without managing servers: functions such as AWS Lambda, Azure Functions and Cloud Run functions, plus managed queues and databases. The attack surface moves to the function's identity, its triggers, its dependencies and its environment variables. See the Serverless Security Guide.
Service account: A non-human identity for workloads. In Google Cloud it is a specific resource type that workloads attach to or impersonate; downloadable service account keys are long-lived and should be blocked by organisation policy where possible. See the Google Cloud Service Account Keys Security Guide.
Service control policy (SCP): An AWS Organizations policy that sets the maximum permissions for IAM users and roles in member accounts. AWS states that no permissions are granted by an SCP; it only limits. SCPs do not affect the management account or service-linked roles. See the AWS Organizations and SCPs Guide.
Service principal: The local representation of an application in a Microsoft Entra tenant, holding its role assignments and credentials (client secrets, certificates or federated credentials). Service principals with high Microsoft Graph or subscription permissions are prime targets. See the Azure RBAC and Service Principals Guide.
Shared responsibility model: The division of security duties between provider and customer. The provider secures the underlying facilities, hardware and its managed services; the customer always remains responsible for its data, identities, access and configuration, and for more layers the further it moves from SaaS towards IaaS. See the Shared Responsibility Models Guide.
Shared fate: A framing, promoted by Google Cloud, in which the provider takes an active part in customer security outcomes through secure defaults, blueprints and guidance, rather than drawing a line and stepping back. See Shared Responsibility vs Shared Fate.
Sovereign cloud: Cloud offerings designed so that data, operations and support stay within a jurisdiction and under its legal control, through local operating entities, residency guarantees and restrictions on provider staff access. See the EU Sovereign Cloud Options Compared Guide.
SSRF (server-side request forgery): A flaw that lets an attacker make a server send requests to destinations of the attacker's choosing, including internal endpoints such as the instance metadata service. The Capital One breach is the best-known cloud case: role credentials obtained through a misconfigured firewall gave read access to far more storage than the role needed.
STS and temporary credentials: Credentials issued for a limited time by a token service, such as AWS STS, Microsoft Entra ID or the Google Cloud token endpoints, after a principal authenticates or a role is assumed. They expire automatically, which shrinks the window in which a stolen credential is useful.

T to Z

Tagging: Key and value labels on resources (tags in AWS and Azure, labels and tags in Google Cloud) recording owner, environment, data classification and cost centre. Consistent tags make it possible to route findings to an owner and to write attribute-based access rules. See the Cloud Resource Tagging Standard Template.
Tenant: A dedicated instance of an identity directory or SaaS service for one organisation. In Microsoft Entra ID the tenant is the identity boundary above subscriptions; compromise of a tenant-level administrator can affect every subscription that trusts it. See the Azure Subscription Compromise Playbook.
Toxic combination: A set of individually moderate findings that together create a serious risk, such as public exposure plus a critical vulnerability plus a privileged attached identity. Google Cloud Security Command Center uses the term for this kind of correlated finding; other platforms describe it as an attack path.
Trust policy: The policy on an AWS IAM role that says which principals may assume it, and under which conditions (external ID, source account, OIDC claims). A trust policy that names an entire external account or omits claim conditions is a frequent source of unintended access. See the AWS IAM Roles vs IAM Users guide.
Unused access: Roles, users, keys, passwords and permissions that exist but have not been used within a set window. AWS IAM Access Analyzer reports unused roles, access keys, passwords and permissions as findings, and the Google Cloud IAM recommender suggests removing permissions a principal has not used. Unused access is the most direct measure of excess privilege.
Virtual private cloud (VPC): A logically isolated network within a provider in which the customer defines address ranges, subnets, routing and gateways: a VPC in AWS and Google Cloud, a virtual network (VNet) in Azure. See the Cloud Network Security Guide.
VPC flow logs: Records of network flows (source, destination, port, protocol, bytes, accept or reject) for a virtual network or interface. They are the main network evidence in cloud investigations, but are not enabled everywhere by default and need a retention decision. See the Cloud Forensics Guide.
VPC Service Controls: A Google Cloud feature that draws a service perimeter around projects so that supported APIs can only be called from inside it, reducing data exfiltration through stolen credentials used from outside. See the Google Cloud VPC and Cloud NGFW Security Guide.
Web application firewall (WAF): A layer 7 filter in front of web applications and APIs that blocks malicious requests using managed and custom rules and rate limits. The WAF's own identity and permissions need the same scrutiny as any workload. See the AWS WAF and Shield Guide.
Workload identity: The identity that a running workload (virtual machine, container, function or pipeline) uses to authenticate, ideally issued by the platform with short-lived credentials rather than embedded as a static secret. See the Cloud Workload Identity Guide.
Workload identity federation: A trust between a cloud identity platform and an external identity provider so that an external workload can exchange its own token for short-lived cloud credentials without stored secrets. All three major providers support it for sources such as Kubernetes clusters and CI/CD systems. See Cross-cloud workload identity federation.
Zero standing privilege: A model in which no identity holds privileged cloud permissions permanently; elevated access is granted just in time, for a task, and removed automatically. See the Cloud PAM and Just in Time Access buyer's guide.
Zero trust: A security model, described in NIST SP 800-207, in which no request is trusted because of network location; every access is authenticated, authorised and evaluated against policy per session. In cloud it shows up as identity-centric access, private endpoints, and continuous evaluation of device and workload posture. See the Zero Trust Identity Guide.

For identity, IAM and non-human identity terms, see the NHI and IAM Glossary. Related NHI Mgmt Group resources: Cloud Security Guide · CNAPP Guide · Cloud Security Maturity Model · Cloud Security Engineer Interview Questions

Cloud Security Glossary: Plain Definitions from CSPM to Workload Identity

A