Most organisations can list their accounts, but few can answer "who and what can actually reach this resource, and through which grant?" without days of manual work. MITRE D3FEND calls the countermeasure Access Modeling (D3-AM) and defines it as capturing and recording "the access permissions granted to identities (e.g., administrators, users, groups, systems)", optionally including "how these identities are stored, managed, and shared across systems." It sits under the Model tactic as a child of Operational Activity Mapping (D3-OAM). This page explains what an access model contains, where the data comes from across directories, cloud platforms and SaaS, how to build and maintain one, how it feeds detection and hardening, and where models mislead. It is written for identity architects, IGA and cloud security teams, and builds on the MITRE D3FEND Operational Activity Mapping Implementation Guide.
Key takeaways
- An access model is a graph, not a list. D3FEND says D3-AM maps Digital Identity, User Account and Access Control Configuration. Useful models join all three: identity, account, group or role, permission and resource.
- Systems are identities too. D3FEND names "systems" alongside administrators, users and groups. Service accounts, workload identities, API keys and AI agents usually hold the broadest and least reviewed access.
- Effective access needs expansion. Nested groups, role definitions and impersonation rights have to be resolved, or the model understates who can reach a resource.
- Deny rules and boundaries break naive models. Tools that analyse only allow policies can report access that another control blocks; state what each source does not evaluate.
- D3FEND relates it to account abuse techniques by inference. Valid Accounts, Account Manipulation, Create Account and Account Discovery appear because they act on the same artefacts.
D3-AM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-AM (d3f:AccessModeling) |
| Tactic | Model |
| Parent technique | Operational Activity Mapping (D3-OAM, synonym "Mission Mapping") |
| Siblings | Operational Dependency Mapping (D3-ODM), Operational Risk Assessment (D3-ORA), Organization Mapping (D3-OM) |
| Ontology relations | Maps Access Control Configuration, Digital Identity and User Account |
| D3FEND reference | IETF RFC 7642, SCIM Definitions, Overview, Concepts, and Requirements |
| Typical sources | Directories, identity providers, cloud IAM policies, SaaS admin APIs, PAM vaults, IGA catalogues, database grants |
| Output | A queryable graph of identities, accounts, groups, roles, permissions and resources, with owners and timestamps |
What an access model contains
| Element | Examples | Why it matters |
|---|---|---|
| Identity | Person, service account, workload identity, AI agent, external partner | Who is accountable; joins accounts across systems |
| Account | AD user, cloud IAM user or role, SaaS user, local admin, database login | The thing that authenticates; one identity has many |
| Credential | Password, access key, certificate, client secret, token | D3FEND's optional "how identities are stored, managed and shared" |
| Grouping | Groups (nested), roles, access packages, permission sets | The indirection that hides effective access |
| Permission | Action on a resource type, with conditions | The actual right being granted |
| Resource | Bucket, database, application, subscription, repository | What can be reached |
| Metadata | Owner, business justification, grant date, last used, source system | Makes review and clean-up possible |
D3FEND's reference, RFC 7642, describes SCIM use cases for moving identities between enterprises and cloud providers through create, update and delete triggers. The SCIM Core Schema, RFC 7643 (Proposed Standard), carries the attributes an access model can ingest: a user's groups (direct, nested or dynamic membership, read-only on the user), entitlements ("a thing the user has"), roles ("who the user is", a label for a set of entitlements) and x509Certificates, and a Group resource's members, which may be users or groups. The SCIM schema defines no vocabulary for entitlements or roles, so normalising them is the modeller's job. See the SCIM Provisioning Guide.
Where identity fits
Non-human identities are where access models earn their keep. A service account in a nested admin group, a cloud role that a CI pipeline can assume, or an OAuth app with tenant-wide mail access are rarely visible in a people-centred review. The model should record each NHI's owner, the systems that use it and the credentials it holds, which ties D3-AM to the work described in NHI Inventory Reconciliation and How to build a service account inventory from Active Directory.
Data sources by platform
Cloud platforms each offer native analysis that can feed an access model. Platforms are listed alphabetically; the order is not a ranking.
| Platform | Native capability (from vendor documentation, November 2026) | What it contributes |
|---|---|---|
| AWS | IAM Access Analyzer: external access analyzer, internal access analyzer and unused access analyzer | Resources shared outside a chosen zone of trust; which principals in the organisation or account can reach selected critical resources; unused roles, access keys, passwords, services and actions |
| Google Cloud | Policy Analyzer for allow policies | Which principals (users, service accounts, groups, domains) have what access to which resources at organisation, folder or project scope, with optional group, role and resource expansion and service account impersonation analysis; long-running queries export to BigQuery or Cloud Storage |
| Microsoft | Microsoft Entra access reviews and Privileged Identity Management | Recorded decisions on group memberships, enterprise application assignments, access package assignments, Microsoft Entra roles and Azure resource roles |
Availability notes. AWS: unused access and internal access analyzers are charged per role, user or resource analysed per month, and external access analysis is per Region. Google Cloud: each organisation gets 20 analysis queries per day at no charge; more needs the Premium or Enterprise tier of Security Command Center at organisation level. Microsoft: access reviews require Microsoft Entra ID Governance or Microsoft Entra Suite, with some capabilities available with Microsoft Entra ID P2.
Each documented scope also defines what to add from elsewhere. Google's documentation, for example, states that Policy Analyzer covers allow policies and does not account for deny policies, Principal Access Boundary policies or Cloud Storage ACLs, so results may show access that another control blocks. Treat every source in the same way: record what it evaluates, and model the rest separately. For Active Directory, graph-based attack path tools resolve nested groups and ACLs; see the BloodHound and Active Directory Attack Path Guide. For SaaS, read admin roles and OAuth grants from each application's admin API.
Building the model
- Pick the questions first. For example: who can administer production, who can read customer data, which NHIs have no owner, which access has not been used in 90 days (an example threshold). The questions decide which sources and how much expansion you need.
- Start with authoritative sources. The identity provider and HR feed for people, directories and cloud IAM for accounts and roles, and the PAM vault and secrets manager for privileged and non-human credentials.
- Correlate accounts to identities. Join on stable identifiers (employee ID, object ID, ARN), not display names. Every account without an identity becomes an orphan finding.
- Expand to effective access. Resolve nested groups, role definitions, permission boundaries and who can impersonate or assume which identities. Record the path, not just the result, so reviewers can see why access exists.
- Add usage. Last-used data from cloud analyzers and sign-in logs separates granted access from exercised access, which is the input least privilege work needs.
- Assign owners. Every privileged grant and every NHI needs a named human owner, or the model cannot drive review. The Entitlement Catalogue Guide covers ownership.
- Refresh and diff. Rebuild on a schedule and on change events. New privileged paths, new external sharing and new NHI credentials become review items.
- Roll back safely. The model only reads. Any remediation it drives (removing grants) should go through change control with a recorded prior state so a wrongly removed grant can be restored.
How it feeds other D3FEND techniques
| Consumer | What it takes from the access model |
|---|---|
| Access policy administration (MITRE D3FEND Access Policy Administration Implementation Guide) | The current state that policy changes start from, and the evidence for removing unused grants |
| Access mediation (MITRE D3FEND Access Mediation Implementation Guide) | Which paths to resources exist and need enforcement points |
| Organization Mapping (D3-OM) and Operational Risk Assessment (D3-ORA) | Which roles and teams hold which access, and which activities are exposed if an identity is compromised |
| Detection engineering | Baselines of expected access, so a first use of a dormant grant or a new privileged path can be alerted on |
See D3-OM Organization Mapping and Least Privilege Techniques Guide.
ATT&CK techniques D3FEND relates to D3-AM
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-AM. Its site shows "inferred and experimental" relations derived from the artefacts D3-AM maps (D3FEND 1.6.0, checked November 2026). Every ID below was checked against ATT&CK v20.
| ATT&CK tactic (v20) | Techniques D3FEND relates by inference | What an access model shows |
|---|---|---|
| Initial Access, Persistence, Privilege Escalation, Stealth | Valid Accounts: Default (T1078.001), Domain (T1078.002), Local (T1078.003), Cloud (T1078.004) | Which accounts exist, what each can reach, and which are unused |
| Persistence, Privilege Escalation | Additional Email Delegate Permissions (T1098.002), Additional Cloud Roles (T1098.003) | New grants appearing between model refreshes |
| Persistence | Create Account: Local (T1136.001), Domain (T1136.002), Cloud (T1136.003) | Accounts with no correlated identity or owner |
| Privilege Escalation | Setuid and Setgid (T1548.001), Temporary Elevated Cloud Access (T1548.005), SID-History Injection (T1134.005), Domain or Tenant Policy Modification (T1484) | Elevation paths and policy objects that change effective access |
| Discovery | Account Discovery: Local (T1087.001), Domain (T1087.002), Cloud (T1087.004); Group Policy Discovery (T1615) | The same view an attacker builds; knowing it first shows what they would find |
| Defense Impairment, Persistence, Credential Access | Conditional Access Policies (T1556.009), File and Directory Permissions Modification (T1222) | Changes to the access control configuration itself |
| Credential Access | Group Policy Preferences (T1552.006) | Where credentials are stored and shared, D3FEND's optional scope |
| Impact | Account Access Removal (T1531) | Unexpected removal of grants or accounts between refreshes |
A model detects none of these by itself. It makes them visible when it is refreshed often and its diffs are reviewed. See the MITRE ATT&CK T1078 Valid Accounts Guide and T1087 and T1069 Account and Permission Group Discovery Defensive Guide.
Measuring it
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) |
|---|---|
| Accounts correlated to an identity with a named owner | Above 98%, NHIs included |
| Privileged grants with recorded justification | 100% |
| Grants unused for 90 days still in place | Falling each quarter |
| Age of the model's oldest source snapshot | Under 24 hours for cloud IAM and the identity provider |
| Systems in scope whose access is in the model | Rising, with critical systems first |
Limits and failure patterns
- Modelling direct grants only: without group, role and impersonation expansion, the model misses the access attackers actually use.
- Ignoring what a source does not evaluate: deny policies, boundaries, resource ACLs and conditions change effective access. Record each source's documented limits beside its data.
- People only: leaving out service accounts, workload identities, API keys and OAuth apps omits most privileged access in modern estates.
- Display-name joins: matching accounts by name creates false links and hides orphans. Use immutable identifiers.
- Stale snapshots: a quarterly export used for daily decisions reports access that no longer exists and misses access that does.
- Model without action: a model that never feeds access reviews or policy change becomes shelfware; tie each finding type to an owner and a workflow (see the Access Reviews Guide).
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 | Identities and credentials for authorised users, services and hardware are managed |
| NIST CSF 2.0 | PR.AA-05 | Access permissions, entitlements and authorisations are defined, managed, enforced and reviewed, with least privilege and separation of duties |
| NIST SP 800-53 Rev 5 | AC-2, AC-2(4) | Account management and automated audit of account actions |
| NIST SP 800-53 Rev 5 | AC-6, AC-6(7) | Least privilege and review of user privileges |
| CIS Controls v8.1 | Safeguards 5.1 and 6.8 | Inventory of accounts; define and maintain role-based access control |
| MITRE D3FEND | D3-OAM, D3-AM | Parent and technique |
Practitioner checklist
- Write down the access questions the model must answer before choosing tools.
- Model identity, account, credential, group or role, permission and resource as separate linked elements.
- Include service accounts, workload identities, API keys, OAuth apps and AI agents with named owners.
- Expand nested groups, role definitions and impersonation or assume-role rights.
- Record what each data source does not evaluate (deny rules, boundaries, ACLs).
- Add last-used data to separate granted from exercised access.
- Refresh at least daily for cloud IAM and the identity provider, and review diffs.
- Route findings to access reviews and policy change with recorded prior state.
Standards and references
- MITRE D3FEND: Access Modeling (D3-AM)
- IETF: RFC 7642 SCIM Definitions, Overview, Concepts, and Requirements
- IETF: RFC 7643 SCIM Core Schema
- AWS: Using AWS Identity and Access Management Access Analyzer
- Google Cloud: Policy Analyzer for allow policies
- Microsoft Learn: What are access reviews?
Related NHI Mgmt Group resources: MITRE D3FEND Operational Activity Mapping Implementation Guide · D3FEND Model Tactic · Identity Attack Paths Guide · Entitlement Catalogue Guide · MITRE D3FEND Guide