Cloud Identity Attack Paths & Privilege: From Assigned Roles to Governed Effective Access

Executive Summary

Cloud identity privilege is often represented as a list of administrators, groups, roles, or entitlements. That view is necessary but incomplete. Effective access can depend on identity-based permissions, resource policies, group inheritance, delegation, federation, service-account impersonation, session conditions, temporary credentials, organizational guardrails, and explicit denies. A meaningful identity attack-path review therefore asks how a human or workload identity can reach or change a critical resource after the relevant control layers are considered.

This report synthesizes current Microsoft guidance on least-privileged administrative roles, AWS IAM Access Analyzer documentation on effective permissions and complex access paths, Google Cloud Policy Analyzer documentation on IAM allow-policy analysis, MITRE ATT&CK Account Manipulation content, CISA visibility and hardening guidance, NIST least-privilege requirements for CUI systems, the IETF OAuth 2.0 Security Best Current Practice, and CIS Control 6 access-management guidance. [1] [2] [3] [4] [5] [6] [7] [8] Each source has a different scope. The report uses them to build an operating model rather than to claim that any named organization has a security weakness.

The core finding is that privilege governance should move from assigned access to explainable effective access. A team should be able to identify the principal, critical resource, applicable policy and trust relationships, credential or token path, conditions, privilege-changing capabilities, owner, approval basis, and review trigger. Where the evidence is incomplete, the defensible status is an evidence gap—not a claim that the path is exploitable or compromised.

CyberTech Intelligence proposes an eight-layer Cloud Identity Attack-Path Governance Framework: Inventory, Resolve, Minimize, Elevate, Bound, Verify, Observe, and Review. The framework is CTI synthesis, not an external standard. It is designed to make a practical principle operational: privilege should become more explainable and more tightly governed as the consequence of the access increases.

Research Methodology and Source Selection

This report is a secondary-research synthesis and CyberTech Intelligence operating-model analysis. Sources were selected for authority, direct relevance, current applicability, and their ability to distinguish identity inventory, administrative privilege, workload identity, effective-access calculation, authorization policy, federation, credentials, monitoring, and access lifecycle. Government and standards sources are used within their stated scope. Vendor documentation is treated as evidence of the named platform's behavior and guidance, not proof of a customer's local configuration, maturity, or exposure.

Microsoft documentation is used for current least-privilege guidance for Entra administrative roles. [1] AWS documentation is used for IAM Access Analyzer concepts, including effective permissions and complex access paths. [2] Google Cloud documentation is used for Policy Analyzer allow-policy analysis and its explicit limitations. [3] MITRE ATT&CK is used for adversary account-manipulation behavior, not for prevalence or target-account findings. [4] CISA guidance is used only within its communications-infrastructure scope to illustrate visibility and hardening practices. [5] NIST SP 800-171 Rev. 3 is used within its CUI protection scope for least-privilege and privileged-function requirements. [6] RFC 9700 is used as current OAuth 2.0 security BCP. [7] CIS Control 6 is used as independent access-management practice guidance. [8]

Quantitative market-adoption claims, vendor performance claims, breach probabilities, and target-account risk scores are intentionally excluded. The campaign does not need a percentage of companies with excessive privilege to establish the operating problem. A product capability can support a scoped statement about that product. An adversary technique can support a scoped statement about attacker behavior. Neither establishes that a named prospect uses the feature, has the weakness, experienced an incident, or will achieve a particular outcome after remediation.

Evidence Universe and Assumptions

The evidence universe covers five connected layers. The first is identity: humans, administrators, service accounts, workloads, applications, federated principals, and other machine identities. The second is authorization: roles, groups, policies, permissions, resource controls, delegation, trust, and explicit deny or boundary mechanisms. The third is credential and session state: authentication, federation, tokens, temporary credentials, activation, and session conditions. The fourth is resource reach: the cloud, SaaS, data, identity, security, and administrative resources that the principal can use or change. The fifth is governance: ownership, approval, exception, review, monitoring, revocation, and evidence.

In this report, “identity attack path” means a defensible representation of how an identity could reach, impersonate, change, or gain privilege over another identity or resource through existing access relationships. The term does not mean the path has been exploited. “Effective access” means the access that results after the relevant authorization relationships and policy controls are considered. The exact calculation is platform-specific; there is no universal cross-cloud evaluator.

“Privilege” is used for access that can materially affect resources, identity, policy, data, security controls, or other principals. Privilege can be direct or inherited, standing or temporary, human or non-human, and local or federated. “Privilege-changing capability” means an action that can alter roles, group membership, policies, credentials, federation, delegation, impersonation, or another control that changes future access. This capability deserves special review because it can create new paths rather than only consume existing access.

Evidence Grading

• Grade A - Final government standards or authoritative government cybersecurity guidance with a defined scope. Permitted use: identity, least-privilege, privileged-function, logging, authentication, and access-control practices within the publication's stated applicability. Government guidance is not evidence of a private organization's local posture.
• Grade B - Maintained independent knowledge bases, Internet standards, and established security-practice specifications. Permitted use: adversary behavior, protocol security practice, access-management safeguards, and technology-neutral concepts within the source's scope. These sources do not certify an implementation.
• Grade C - Current primary platform documentation. Permitted use: the named platform's authorization model, access-analysis capability, policy behavior, identity type, limitation, or workflow. It is not evidence that a target organization uses the capability or that its configuration is correct.
• Grade D - CyberTech Intelligence synthesis derived from cited evidence. Permitted use: the framework, readiness model, metrics, maturity stages, roadmap, decision-rights structure, and implementation guidance clearly labeled as CTI analysis. Grade D content is an editorial operating model, not an industry standard or certification.

Research Limitations

No external source can establish the effective access of an individual organization's identities without current local configuration and, in some cases, runtime evidence. Platform documentation describes how a service is designed to evaluate or report access. It does not prove the current policies, trust relationships, groups, resource hierarchy, identity lifecycle, credential state, or exceptions in a particular environment.

Access-analysis tools also have scope and freshness boundaries. Google Cloud Policy Analyzer for allow policies explicitly states that it analyzes IAM allow policies, does not account for several other access-control mechanisms such as deny policies, and uses best-effort Cloud Asset data freshness. [3] AWS IAM Access Analyzer documents scope and supported-resource considerations for its different analyzers. [2] A tool output should therefore be interpreted as evidence within its documented coverage, not a complete cross-platform truth by default.

Adversary knowledge must be separated from local findings. MITRE ATT&CK documents ways adversaries can manipulate accounts, credentials, groups, and cloud roles. [4] That supports threat-informed prioritization of privilege-changing capabilities. It does not establish that the technique is present in a named environment. Similarly, least-privilege guidance does not prove that any existing permission is unnecessary until the operating purpose and dependency are reviewed.

Key Terminology Distinctions

• Identity - A human, workload, service, application, federated, or other principal represented to an identity or authorization system. Identity type matters because authentication, credentials, lifecycle, and review mechanisms differ.
• Assigned access - A role, entitlement, group membership, permission, or policy relationship visible in a specific system. Assigned access is evidence of configuration, not always the complete effective-access result.
• Effective access - The actions a principal can actually perform on a resource after applicable grants, restrictions, conditions, boundaries, resource policies, organizational controls, and other authorization relationships are considered.
• Identity attack path - A modeled sequence of access or privilege relationships through which an identity could reach or influence a resource or another identity. A modeled path is not proof of exploitation or compromise.
• Workload identity - An identity used by software such as an application, service, automation process, or pipeline rather than by an interactive human. The specific object type and credential model vary by platform.
• Delegation/impersonation - A relationship that allows one principal to act through or as another identity under defined platform rules. It can be an intended administration or workload pattern and should be evaluated for scope and ownership.
• Temporary privilege - Access or credentials that expire or are activated for a bounded interval. Temporary access can reduce standing exposure in some designs, but it still requires appropriate scope, approval, monitoring, and revocation behavior.
• Guardrail - A policy control that restricts the maximum, prohibited, contextual, or organizational scope of permissions without necessarily granting the underlying access. The exact semantics vary by platform.
• Readiness score - An internal CyberTech Intelligence assessment aid based on eleven evidence domains; not a certification, audit, external rating, legal conclusion, product score, security guarantee, or prediction.

Research Framework

Findings are organized through the CyberTech Intelligence Cloud Identity Attack-Path Governance Framework™: Inventory, Resolve, Minimize, Elevate, Bound, Verify, Observe, and Review. The framework is tool-agnostic. It does not prescribe a product or require every privilege to be temporary. It asks whether the organization can explain current effective access, justify necessary privilege, constrain unnecessary reach, verify control behavior, and remove access when purpose ends.

Executive Findings

• Microsoft Entra role guidance recommends least privilege across permissions, scope, and time, and advises avoiding broader roles and scopes when narrower assignments meet the task. [1]
• AWS IAM Access Analyzer documents internal-access findings that can identify effective permissions and complex access paths created by combinations of identity and resource policies. [2]
• Google Cloud Policy Analyzer can answer who has what IAM allow-policy access to which resources, but its documentation explicitly excludes several other access-control mechanisms and notes best-effort data freshness. [3]
• MITRE ATT&CK Account Manipulation covers adversary changes to credentials, permission groups, cloud roles, and related account properties to maintain or elevate access. [4]
• NIST SP 800-171 Rev. 3, within its CUI protection scope, includes requirements to restrict privileged accounts, use non-privileged accounts for non-security functions, prevent non-privileged execution of privileged functions, and log privileged functions. [6]
• RFC 9700 updates OAuth 2.0 security best current practice based on operational experience and newer threats, reinforcing that federation and authorization-token flows require protocol-level security discipline in addition to role governance. [7]
• CIS Control 6 defines access-control management as creating, assigning, managing, and revoking credentials and privileges for user, administrator, and service accounts, with minimal authorization and recurring access review among its practices. [8]

Identity Risk Has to Be Evaluated as Paths, Not Isolated Accounts

A privileged-account list answers “who has a role?” It does not necessarily answer “what can this principal reach?” A cloud identity may gain access through nested groups, a resource policy, a cross-account trust, service-account impersonation, application consent, delegated administration, federation, or a role that can change other roles. For critical resources, the unit of analysis should therefore be the path between principal and resource rather than the account object in isolation.

MITRE ATT&CK's Account Manipulation technique highlights why privilege-changing actions deserve special attention. The technique includes changing credentials or permission groups and includes cloud-specific sub-techniques such as additional cloud credentials and roles. [4] The defensive implication is not that every role change is suspicious. It is that the ability to change identities, credentials, or permissions can create or preserve future access and should be treated as a higher-consequence capability.

A path record should include the starting identity, resource, direct and inherited assignments, delegation or impersonation, trust and federation, privilege-changing rights, applicable guardrails, and known conditions. When one of those relationships cannot be resolved, record it as an evidence gap. Do not label the path “exploitable” unless the evidence supports that stronger claim.

Effective Access Emerges from Multiple Policy and Permission Layers

Cloud authorization is compositional. AWS IAM Access Analyzer documents internal access analysis that evaluates effective permissions and can identify complex paths based on combinations of identity and resource policies. [2] Google Policy Analyzer answers allow-policy questions across a resource hierarchy but explicitly says its results do not account for IAM deny policies and other access mechanisms. [3] Together, these examples show why role exports are a starting point rather than a final access verdict.

The governance model should preserve platform-specific evaluation semantics instead of forcing every cloud into one generic formula. For each critical path, identify which controls can grant access, which can restrict it, which conditions matter, and which tools can calculate or simulate the result. If a product's analyzer has coverage limitations, those limitations belong in the evidence record.

This distinction matters during remediation. Removing one role may not remove effective access if another resource or group policy still grants it. Conversely, a broad role name may not translate into broad usable access when a restrictive boundary or deny control applies. The control objective is to change the effective path intentionally, then verify the new state rather than assume the configuration edit had the desired result.

Workload and Service Identities Need Ownership, Lifecycle, and Least Privilege

Workload identities are operational dependencies, not merely technical accounts. They may run services, deployments, data pipelines, integration jobs, security tools, or automation that must continue after the human who created them changes role or leaves. A workload identity therefore needs an accountable application or service owner, a clear credential or federation method, resource scope, impersonation relationships, and a retirement event tied to the workload lifecycle.

CIS Control 6 explicitly includes service accounts in access-control management and calls for processes to create, assign, manage, and revoke credentials and privileges, with minimal authorization appropriate to role. [8] Microsoft Entra administrative-role guidance similarly recommends granting administrators the permissions needed for the task, at an appropriate scope and period of time. [1] These sources have different scopes, but both support making privilege purposeful rather than inherited by convenience.

The practical test is not whether the identity is “non-human.” It is whether the organization can answer: which workload uses it, which resources it can reach, how it authenticates, who can alter its trust or credentials, whether it can impersonate another identity, what happens if access is removed, and who is responsible for review. A service account without a named operating owner is a governance gap even if its technical configuration is valid.

Standing Privilege Should Be Distinguished from Temporary Elevation

Not every privileged task requires a permanently active permission, and not every privileged workflow can be made temporary without operational cost. The design decision should therefore be evidence-led: which functions need continuous access, which can use eligible or just-in-time activation, which workloads can use temporary credentials, and which emergency paths require a separately governed exception.

NIST SP 800-171 Rev. 3 requires, for systems in its CUI scope, restricting privileged accounts to defined personnel or roles and requiring privileged users to use non-privileged accounts for non-security functions; it also requires preventing non-privileged users from executing privileged functions and logging privileged-function execution. [6] Those requirements should not be generalized into a universal commercial mandate, but they illustrate the operational separation between privileged and ordinary activity.

A mature privilege record should distinguish assignment from activation. For a human, record eligibility, activation, approver, duration, and privileged session evidence where available. For a workload, record the temporary credential or token mechanism, the role assumed, lifetime, trust condition, and revocation behavior. For an exception, state why standing privilege is required and when that decision will be reviewed.

Guardrails: Change the Reachable Permission Surface

Guardrails are valuable only when their place in the authorization chain is understood. Some controls limit maximum permissions, some deny specific actions, some restrict organizational scope, and some constrain access by context. A review that records only grants can overstate exposure when restrictive controls apply; a review that assumes a guardrail covers every identity type can understate exposure when coverage is narrower than expected.

Google Policy Analyzer provides a useful caution: its IAM allow-policy analysis does not account for deny policies, Principal Access Boundary policies, certain Kubernetes controls, Cloud Storage ACLs, and other mechanisms listed in its documentation. [3] The correct response is not to reject the tool. It is to pair the result with an evidence statement describing which policy types were and were not included.

CyberTech Intelligence recommends a guardrail register linked to critical resources and privilege-changing roles. For each guardrail, record scope, owner, prohibited or maximum permissions, exceptions, identity classes covered, validation method, and change trigger. That allows the program to distinguish “a control exists” from “the control demonstrably constrains this path.”

Review and Revocation Must Be Evidence-Led and Continuous

Privilege does not become safe because it passed one review. Workloads change, people change jobs, SaaS integrations expand, cloud projects move, role definitions evolve, resource policies are edited, and federation mappings change. Review must therefore combine scheduled recertification with event-driven triggers that can materially alter effective access.

CISA's Enhanced Visibility and Hardening Guidance for Communications Infrastructure is tailored primarily to communications infrastructure and is not a general cloud IAM standard. Within that scope, the guidance emphasizes visibility and hardening practices for administrators and defenders. [5] The broader lesson for this report is limited but useful: identity and access decisions are easier to govern when changes and privileged actions produce reviewable evidence rather than disappearing into configuration history.

Revocation should be tested as an operating capability. When an employee leaves, a workload is retired, a vendor relationship ends, an exception expires, or a privileged role is no longer needed, the organization should know which role, group, federation, credential, application consent, service account, and resource relationship must change. Closure evidence should show that the intended path was actually removed or narrowed.

Board-Level Evidence and Decision Metrics

• Critical-resource path coverage: percentage of priority cloud and SaaS resources for which the organization can identify human and workload administrators and reconstruct material effective-access paths.
• Identity ownership completeness: percentage of material privileged human, service, workload, federated, and application identities with a current accountable owner and lifecycle state.
• Effective-access evidence coverage: percentage of priority paths with current policy, group, resource, trust, delegation, and guardrail evidence sufficient to explain the authorization result.
• Standing-versus-temporary privilege: distribution of high-consequence privileges by standing, eligible, temporary, emergency, or exception state; treat the mix as context, not an automatic quality score.
• Workload credential posture: percentage of priority workload identities with a documented credential or federation method, owner, expiry/rotation or token behavior, resource scope, and retirement trigger.
• Privilege-change monitoring: percentage of material role, group, policy, federation, credential, or service-identity changes routed to an accountable review process.
• Review-to-revocation closure: percentage of access-review decisions to remove or reduce privilege that are followed by verified closure evidence rather than only a ticket status.
• Exception health: count and age of privilege exceptions without a current owner, expiry/review date, compensating control, or evidence that the exception remains necessary.

Twelve-Month Implementation Roadmap

• 0-90 days: select a small set of critical cloud and SaaS resources; inventory privileged humans and workloads; map roles, groups, resource policies, delegation, federation, credentials, and guardrails; define identity owners and a minimum path record; test one end-to-end review from inventory through privilege reduction or confirmed retention.
• 3-6 months: standardize identity and resource ownership, effective-access evidence, service-account lifecycle, federation records, privilege classification, exception templates, revocation verification, and change-trigger routing; create a backlog of unresolved path relationships and stale privilege.
• 6-9 months: expand path analysis to additional critical resources and SaaS platforms; integrate temporary or just-in-time privilege where it meets operational needs; improve workload federation and credential governance; add routine path re-analysis after role, policy, identity, and resource changes.
• 9-12 months: compare evidence quality across clouds and business units; automate inventory and path-diff collection where product coverage is understood; retire orphaned identities and obsolete exceptions; use measured review and revocation outcomes to refine which privileges can be streamlined and which require stronger decision controls.

Strategic Takeaway

Cloud identity attack paths should not be governed as a fear-led statement that every privileged account is one step from compromise. They should be governed as a chain of authorization evidence. A credible program can inventory the identities and resources, resolve effective access, minimize unnecessary reach, Elevate privilege deliberately, bound it with appropriate guardrails, verify the resulting control state, observe material changes, and review or revoke privilege when purpose changes.

That model keeps claims proportional to evidence. A role assignment is evidence of assignment. A policy analyzer result is evidence within the tool's documented coverage. A sign-in or audit record is evidence of activity. An incident record is evidence of a security event. Governance improves when those evidence types are connected without being conflated.

Governance and Decision Rights

• Identity intake and ownership - Accountable owner: IAM or identity-governance lead with business/workload owner. Required evidence: identity type, owner, purpose, lifecycle, credential or federation method, critical-resource relationship. Exit criterion: identity is in scope with an accountable owner or escalated as an ownership gap.
• Effective-access resolution - Accountable owner: cloud/IAM platform owner with resource owner. Required evidence: roles, groups, resource policies, trust, delegation, impersonation, boundaries, conditions, guardrails, analyzer scope and limitations. Exit criterion: path is explainable or unresolved edges are explicitly recorded.
• Privilege approval - Accountable owner: designated access authority or resource owner under policy. Required evidence: task or business purpose, requested permissions, consequence, duration, alternative scope, approval basis, exception if needed. Exit criterion: privilege is granted, narrowed, returned for evidence, or denied.
• Workload and federation governance - Accountable owner: application/workload owner with IAM platform owner. Required evidence: issuer/trust, subject mapping, service or workload identity, credential/token method, impersonation, resource access, deployment dependency, retirement trigger. Exit criterion: trust and privilege are bounded and owned.
• Material exception and residual uncertainty - Accountable owner: risk or business authority with security/identity owner. Required evidence: current facts, missing evidence, reason, scope, compensating action, expiry, review trigger. Exit criterion: exception remains bounded and reviewable or is closed.
• Lifecycle review and revocation - Accountable owner: identity/resource owner. Required evidence: usage or activation evidence where available, role/policy changes, current need, owner status, exception age, revocation test, next trigger. Exit criterion: access is retained, changed, reduced, or removed with rationale and closure evidence.

CyberTech Intelligence Cloud Identity Attack-Path Governance Framework™

1. Inventory: Identify critical resources and the human, workload, service, federated, and administrative identities that can use or change them; record owners, purpose, and lifecycle state.
2. Resolve: Reconstruct effective access through roles, groups, resource policies, federation, delegation, impersonation, conditions, permission boundaries, organizational guardrails, and explicit denies; preserve analyzer scope and limitations.
3. Minimize: Compare privilege with the authorized operating purpose; reduce unnecessary scope, remove stale access, and avoid duplicate paths only after dependency evidence is understood.
4. Elevate: Distinguish standing, eligible, temporary, and emergency privilege; define activation, justification, approval, duration, credential/session evidence, and exceptions appropriate to consequence.
5. Bound: Apply and validate guardrails, deny controls, permission boundaries, organizational restrictions, and context controls that limit reachable actions or resources without being confused with the grants themselves.
6. Verify: Confirm that intended access works under current identity, credential, policy, resource, and session conditions and, where practical, that prohibited paths are actually constrained.
7. Observe: Monitor material changes to identities, roles, groups, policies, federation, delegation, workloads, credentials, and critical resources; retain evidence sufficient to explain current state and route change for review.
8. Review: Re-certify purpose and ownership, expire or revoke stale privilege, close or renew bounded exceptions, and re-run path analysis after changes that can alter effective access.

Cloud Identity Attack-Path Readiness Score™

Rate each domain from 0 to 4: 0 = absent; 1 = informal; 2 = documented; 3 = implemented and tested; 4 = measured and continuously improved. Maximum score: 44. Readiness percentage = total score divided by 44, multiplied by 100. Suggested interpretation: Basic 0-24%; Developing 25-49%; Defined 50-69%; Managed 70-84%; Adaptive 85-100%. This is an internal CyberTech Intelligence assessment aid, not a certification, external rating, audit, legal conclusion, security guarantee, or forecast.

• Identity Inventory & Ownership - Ready-state evidence: current human, workload, service, federated, application, and administrative identity inventory with owner, purpose, lifecycle state, and critical-resource relationship.
• Effective Access & Path Visibility - Ready-state evidence: role/group inheritance, resource policies, trust, delegation, impersonation, conditions, guardrails, analyzer scope, unresolved edges, and path owner for priority resources.
• Human Administrative Privilege - Ready-state evidence: role purpose, scope, standing/eligible/temporary state, approval, authentication and activation evidence, emergency treatment, review date.
• Workload & Service Identity Governance - Ready-state evidence: workload owner, service identity, credential/federation method, permissions, impersonation, lifecycle event, deployment dependency, retirement plan.
• Federation, Delegation & Impersonation - Ready-state evidence: issuer/trust, subject/group mapping, delegation grants, service-account impersonation, cross-boundary access, owner, change history, audit evidence.
• Temporary / Just-in-Time Privilege - Ready-state evidence: eligibility, request and justification, approval if required, maximum duration, activation/session record, expiry, emergency exception.
• Policy Guardrails & Permission Boundaries - Ready-state evidence: restrictive controls, scope, owner, protected permissions/resources, coverage boundaries, exceptions, validation result, change trigger.
• Cloud / SaaS Resource Access - Ready-state evidence: critical-resource owner, administrative interfaces, allowed identity classes, current access evidence, dependency and recovery considerations.
• Credentials, Tokens & Session Controls - Ready-state evidence: credential or federation method, token/session flow, lifetime, contextual controls, secret/key exceptions, revocation route, relevant logs.
• Monitoring, Change & Path Detection - Ready-state evidence: role, group, policy, trust, identity, credential, workload, and resource changes are captured and routed to path-diff or review processes with accountable owners.
• Evidence, Review & Revocation - Ready-state evidence: source links, decision history, current owner, exception/expiry, last review, retain/change/revoke result, and verified closure evidence.

Cloud Identity Attack-Path Maturity Model

• Reactive - Privilege is reviewed mainly after incidents, audit requests, access problems, or staff changes. Identity ownership and workload lifecycle are inconsistent. Leadership priority: establish a critical-resource inventory, identity owners, and minimum path evidence.
• Defined - Priority identities and resources, path records, role and policy evidence, temporary-access patterns, workload ownership, guardrails, exceptions, and review triggers are documented. Leadership priority: standardize effective-access resolution and revocation verification.
• Controlled - Material paths have repeatable evidence, tested control behavior, privilege classification, change-triggered review, exception expiry, workload lifecycle governance, and verified access reduction or revocation. Leadership priority: reduce unresolved paths and standing privilege that lacks evidence.
• Adaptive - Identity-path priorities, temporary-access patterns, review depth, automation, and guardrails evolve from measured change, usage, access analysis, workload lifecycle, and revocation evidence. Leadership priority: automate evidence collection and low-consequence decisions while keeping high-consequence authority explicit.

About CyberTech Intelligence

CyberTech Intelligence provides research-led cybersecurity intelligence, executive content, and market engagement programs. This publication is vendor-neutral and intended for education, decision support, and claim-safe GTM planning.

Research and Citation Governance

External research is used within each source's stated scope. NIST and CISA material provides government guidance for the environments it addresses; MITRE ATT&CK provides maintained adversary-behavior knowledge; RFC 9700 provides an Internet Best Current Practice for OAuth 2.0; CIS provides independent access-management guidance; Microsoft, AWS, and Google Cloud documentation describes named platform behavior. CyberTech Intelligence does not convert any source into a statement about a target organization's local posture or outcome. The CTI framework, readiness score, maturity model, metrics, and roadmap are editorial operating models for decision support.

References

1. Microsoft Learn, “Best practices for Microsoft Entra roles.” Current documentation. Relevance: Microsoft recommends least privilege for administrators across permission set, scope, and time and cautions against broader roles or scopes when narrower access meets the task. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices 
2. Amazon Web Services, “Understand how IAM Access Analyzer findings work.” Current documentation. Relevance: AWS documents internal-access analysis of effective permissions and complex paths based on identity and resource policies, plus separate unused-access analysis. https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-concepts.html  
3. Google Cloud, “Analyze allow policies.” Current documentation. Relevance: Google documents Policy Analyzer queries for who has what IAM allow-policy access to which resources, while stating supported-policy and data-freshness limitations. https://docs.cloud.google.com/policy-intelligence/docs/analyze-iam-policies  
4. MITRE ATT&CK, “Account Manipulation (T1098).” Version 2.8, last modified May 12, 2026. Relevance: MITRE documents adversary manipulation of accounts, credentials, permission groups, cloud roles, and related access mechanisms for persistence or privilege escalation. https://attack.mitre.org/techniques/T1098/ 
5. CISA and partners, “Enhanced Visibility and Hardening Guidance for Communications Infrastructure.” Published December 4, 2024. Relevance: within its communications-infrastructure scope, the guidance addresses visibility and hardening practices for administrators and defenders. https://www.cisa.gov/resources-tools/resources/enhanced-visibility-and-hardening-guidance-communications-infrastructure  
6. NIST, “SP 800-171 Rev. 3: Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations.” Final. Relevance: within its CUI protection scope, NIST includes least-privilege requirements for privileged accounts and functions and logging privileged-function execution. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/800-171r3/NIST.SP.800-171r3.html 
7. IETF, “RFC 9700: Best Current Practice for OAuth 2.0 Security.” January 2025. Relevance: RFC 9700 updates OAuth 2.0 security best current practice based on operational experience and newer threats affecting authorization flows. https://www.rfc-editor.org/rfc/rfc9700.html  
8. Center for Internet Security, “CIS Control 6: Access Control Management.” CIS Controls Assessment Specification for Controls v8. Relevance: CIS defines processes to create, assign, manage, and revoke access credentials and privileges for user, administrator, and service accounts and emphasizes minimal authorization and review. https://cas8.docs.cisecurity.org/en/latest/source/Controls6/