Identity in the cloud and zero trust

In cloud environments, identity is the primary security control. There is no data center door, no internal network to trust and often no firewall between an attacker on the internet and the cloud provider's management interface: anyone with valid credentials and the right permissions can create, read or destroy resources from anywhere. This lesson covers identity as a service, hybrid identity, the explosion of non-human identities such as cloud roles and API keys, secrets management, cloud entitlement management and how identity anchors zero trust architectures. It builds on the network view of zero trust in CISSP-113 and the authorization architecture in lesson 8.

Identity as a service and hybrid identity

Identity as a service, IDaaS, delivers directory, authentication, single sign-on, multifactor authentication and often governance as a cloud service. Microsoft Entra ID, Okta, Google Cloud Identity, Ping Identity and others operate the identity provider for thousands of customers, giving them modern protocols, global availability and rapid security features without running their own servers. The trade-offs are dependence on the provider's availability and security, the need to understand the shared responsibility split, and data residency questions about where identity data and logs are stored, which matter under Canadian and US privacy and public-sector rules.

Most established organizations run hybrid identity: an on-premises directory, usually Active Directory, remains the source for many systems, and a synchronization service copies identities, and sometimes password hashes, to the cloud identity provider. Authentication can then happen in the cloud using synchronized password hashes, by passing through to on-premises domain controllers or by federating with an on-premises identity provider. Each option has security consequences. Synchronization servers and federation servers hold credentials or signing keys that can impersonate any user, so they are Tier 0. Attackers who compromised on-premises federation servers have forged tokens for cloud services, which is why many organizations now prefer cloud authentication with phishing-resistant MFA and treat the link between on-premises and cloud as a critical trust boundary.

Non-human identities

Applications, scripts, containers, virtual machines, CI/CD pipelines and SaaS integrations all authenticate to each other and to cloud services. These non-human or machine identities include cloud IAM roles, service principals, managed identities, API keys, OAuth client credentials, SSH keys and certificates. In most organizations they now outnumber people many times over, and they are often over-privileged, long-lived, poorly inventoried and invisible to the processes built for human joiners and leavers. Leaked access keys committed to public code repositories are found by automated scanners within minutes and used to run cryptocurrency miners or steal data.

The safest secret is one that does not exist. Cloud platforms offer managed or workload identities, where a virtual machine, function or container is given an identity by the platform and receives short-lived credentials automatically, with no long-term key for anyone to copy. Workload identity federation lets workloads outside a cloud, such as a CI/CD pipeline or a Kubernetes cluster, exchange a token from their own platform for short-lived cloud credentials, again without stored keys. Open standards such as SPIFFE give workloads verifiable identities across environments. Where secrets cannot be avoided, they belong in a secrets manager or vault, never in code, configuration files or chat messages, and they should be rotated automatically and scoped narrowly.

from datetime import date
today = date(2026, 10, 19)
keys = [  # (identity, credential type, created, last used, owner)
    ('ci-deploy', 'static access key', date(2023, 2, 1), date(2026, 10, 18), 'platform-team'),
    ('legacy-report', 'static access key', date(2021, 6, 9), date(2024, 1, 15), None),
    ('web-app', 'managed identity', None, date(2026, 10, 19), 'web-team'),
    ('etl-job', 'client secret', date(2026, 5, 2), date(2026, 10, 17), 'data-team'),
    ('old-poc', 'SSH key', date(2022, 11, 30), None, None),
]
for ident, kind, created, used, owner in keys:
    issues = []
    if created and (today - created).days > 365:
        issues.append(f'secret {(today - created).days} days old')
    if used is None or (today - used).days > 90:
        issues.append('unused for 90+ days')
    if owner is None:
        issues.append('no owner')
    if kind == 'managed identity':
        issues = issues or ['no stored secret']
    print(f'{ident:13s} {kind:18s} ' + ('; '.join(issues) if issues else 'ok'))

ci-deploy     static access key  secret 1356 days old
legacy-report static access key  secret 1958 days old; unused for 90+ days; no owner
web-app       managed identity   no stored secret
etl-job       client secret      ok
old-poc       SSH key            secret 1419 days old; unused for 90+ days; no owner

Cloud entitlement management and identity threat detection

Cloud platforms offer thousands of distinct permissions, and roles often accumulate far more than they use. Cloud infrastructure entitlement management, CIEM, tools analyze which identities hold which permissions, compare granted permissions with those actually used, flag risky combinations such as the ability to modify one's own policies, and recommend right-sized policies. Identity threat detection and response, ITDR, focuses on detecting attacks against identity systems themselves: suspicious changes to federation settings, new credentials added to privileged service principals, unusual token issuance, impossible travel and attempts to disable logging. Both depend on comprehensive identity logs being collected and retained.

granted = {  # permissions attached to a role
    'storage:Read', 'storage:Write', 'storage:Delete', 'compute:Start', 'compute:Stop', 'compute:Create',
    'iam:AttachPolicy', 'iam:CreateKey', 'logs:Delete', 'kms:Decrypt',
}
used_90_days = {'storage:Read', 'storage:Write', 'compute:Start', 'compute:Stop', 'kms:Decrypt'}
unused = sorted(granted - used_90_days)
risky = {'iam:AttachPolicy': 'can grant itself more power', 'iam:CreateKey': 'can mint new credentials', 'logs:Delete': 'can erase evidence'}
print(f'Granted {len(granted)}, used {len(used_90_days)}, unused {len(unused)} ({len(unused) / len(granted):.0%})')
for p in unused:
    print(f'  remove {p:18s} {risky.get(p, "")}')
print('Right-sized policy:', sorted(used_90_days))

Granted 10, used 5, unused 5 (50%)
  remove compute:Create     
  remove iam:AttachPolicy   can grant itself more power
  remove iam:CreateKey      can mint new credentials
  remove logs:Delete        can erase evidence
  remove storage:Delete     
Right-sized policy: ['compute:Start', 'compute:Stop', 'kms:Decrypt', 'storage:Read', 'storage:Write']

Usage-based right-sizing needs care. Some permissions are used rarely but legitimately, such as disaster recovery actions, and removing them can break recovery when it is needed most. Such permissions are better moved to a separate role available through just-in-time elevation than left on everyday roles or removed entirely.

Identity in zero trust architectures

Zero trust, described in NIST SP 800-207, treats every access request as if it came from an untrusted network. Identity is its foundation: each request is authenticated and authorized using the identity of the user or workload, the state of the device, the sensitivity of the resource and contextual signals, and access is granted per session with least privilege. In NIST's terms, a policy engine decides, a policy administrator establishes or tears down the session, and policy enforcement points sit in front of resources, the same pattern as the PDP and PEP in lesson 8. Practical building blocks include a strong identity provider with phishing-resistant MFA, device management that reports health, conditional access policies, identity-aware proxies in front of applications and continuous evaluation of sessions.

Continuous access evaluation closes the gap between a decision and a change in circumstances. Traditionally, an access token remains valid until it expires, even if the user is disabled or the device is found to be compromised a minute after issue. Continuous evaluation lets the identity provider signal relying services in near real time about critical events, such as account disablement, password change or detected risk, so that sessions end promptly. Open standards from the OpenID Foundation, the Shared Signals Framework with its Continuous Access Evaluation Profile, CAEP, and Risk Incident Sharing and Coordination, RISC, standardize these signals between providers and applications.

In the United States, OMB memorandum M-22-09 set a federal zero trust strategy with identity at its core, requiring agencies to use centralized identity systems, phishing-resistant MFA and attribute-based authorization, and CISA's Zero Trust Maturity Model, version 2.0, describes progress across five pillars, the first of which is identity. Federal cloud services used by agencies must be FedRAMP authorized, which includes identity and access controls drawn from NIST SP 800-53. Private-sector organizations widely use the CISA model as a roadmap. Checked October 2026.

Thinking like a manager

Cloud identity questions test whether you recognize that permissions are the perimeter. Favor answers that centralize identity, protect the identity provider and its trust links as Tier 0, eliminate long-lived secrets in favor of managed and federated workload identities, right-size permissions using evidence, collect and analyze identity logs and evaluate access continuously. When a zero trust question asks where to begin, identity and strong authentication are almost always the right foundation.

Identity logs as evidence

Every design in this lesson depends on identity logs: sign-ins with their authentication method and device, token issuance, consent grants, changes to roles, policies and federation settings, and the use of privileged and non-human identities. Cloud identity providers keep these logs for limited periods by default, sometimes only 7 to 30 days on lower service tiers, which is shorter than the time many intrusions go undetected. A manager should make sure identity logs are exported to the organization's own SIEM or log archive, retained for at least a year or as long as regulation and investigation needs require, protected from alteration and covered by detections. The most valuable alerts include new credentials added to service principals or applications, changes to federation trust or signing certificates, sign-ins that bypass conditional access, mass consent to a new application, disabling of audit logging and use of break-glass accounts.