When an account is compromised or a server goes down, the first question from leadership is what the business can no longer do, and most security teams cannot answer it from their own data. MITRE D3FEND calls the work that answers it Operational Activity Mapping (D3-OAM, synonym Mission Mapping), a technique in the Model tactic with four children: Organization Mapping, Operational Dependency Mapping, Access Modeling and Operational Risk Assessment. This guide treats D3-OAM as a programme: what each child produces, how they connect to asset and network models, which to build first, how to keep them current and where they fail. It is written for security architects, risk and resilience leads, and identity governance teams. For D3FEND itself, see the MITRE D3FEND Guide.
Key takeaways
- D3-OAM models the organisation, not the network. D3FEND defines it as identifying the organisation's activities and the suborganisations, groups, roles and individuals that carry them out, then establishing how those activities depend on systems and people.
- Its four children build on each other. Organization Mapping (who), Operational Dependency Mapping (what depends on what), Access Modeling (who can do what) and Operational Risk Assessment (what could go wrong, and how badly).
- Access Modeling is where identity teams own the work. D3FEND defines it as recording the permissions granted to identities, including administrators, users, groups and systems, and cites the SCIM requirements RFC as a reference.
- The ATT&CK links are identity heavy. D3FEND's inferred mappings for D3-OAM centre on Valid Accounts, Account Manipulation, Create Account and Account Discovery, labelled "inferred, experimental".
- Its value appears in incidents and in prioritisation. A dependency model turns "host X is compromised" into "payroll and supplier payments are at risk", which changes the response and the budget.
What D3FEND means by Operational Activity Mapping
D3-OAM sits in the Model tactic with Asset Inventory (D3-AI), Network Mapping (D3-NM) and System Mapping (D3-SYSM). Those three describe technology; D3-OAM describes the organisation that uses it. D3FEND references the Unified Architecture Framework (UAF) from the Object Management Group and modelling tools built on it, and its Operational Dependency Mapping references include mission dependency and mission impact research such as MITRE's Cyber Command System (CYCS) and the Johns Hopkins APL Dagger work. The common idea is a layered model: business activities at the top, the people and roles that perform them, the applications and services they use, and the infrastructure beneath.
In civilian terms D3-OAM overlaps with business impact analysis, service mapping and crown jewels analysis. What D3FEND adds is the explicit link to defensive and offensive techniques: the model is there to inform detection priorities, hardening and response, not only continuity planning. Our recommendation at NHI Mgmt Group is to reuse existing continuity and service mapping work as the starting point, rather than building a separate security model.
Every child technique
The table lists every child of D3-OAM in the D3FEND ontology with its purpose and the artefacts D3FEND relates it to.
| Technique | Purpose (from D3FEND) | Artefacts in the ontology |
|---|---|---|
| Organization Mapping (D3-OM) | Identify and model the people, roles and groups within an organisation and the relations between them | Maps Organization, Person, Dependency; may map Operational Activity Plan |
| Operational Dependency Mapping (D3-ODM) | Model the dependencies of activities on each other and on performers (people, systems and services), including higher and lower level activity layers | Maps Dependency, Operational Activity Plan |
| Access Modeling (D3-AM) | Record the access permissions granted to identities, optionally with how identities are stored, managed and shared across systems | Maps Access Control Configuration, Digital Identity, User Account |
| Operational Risk Assessment (D3-ORA) | Model the vulnerabilities of, and risks to, activities individually and as a whole (synonym: Mission Risk Assessment) | Evaluates Organization; identifies Vulnerability |
D3FEND's references for Operational Risk Assessment are NIST risk management documents, including SP 800-37 Rev. 2, SP 800-53A Rev. 5, SP 800-160 Volume 1 and NISTIR 8011 Volume 1, which signals that D3-ORA is meant to align with existing risk management practice rather than replace it.
What delivers each child in practice
Each child usually already exists somewhere in the organisation, under a different name and owner. The mapping below is our NHI Mgmt Group view.
| Child | Existing artefact to reuse | Usual owner | Security enrichment to add |
|---|---|---|---|
| D3-OM | HR organisation data, directory groups, RACI charts | HR, IAM | Owners for every system and every non-human identity |
| D3-ODM | Business impact analysis, CMDB service maps, architecture repositories | Resilience, enterprise architecture | Identity providers, secrets stores and CI/CD pipelines as dependencies |
| D3-AM | IGA entitlement catalogue, cloud IAM policy exports, role models | Identity governance | Effective permissions including service accounts, API keys and delegated OAuth grants |
| D3-ORA | Enterprise and operational risk registers | Risk management | Risks expressed per business activity, linked to the dependencies and access above |
For the inputs see the Business Impact Analysis Template, Crown jewels analysis and the Entitlement Catalogue Guide.
Choosing, combining and sequencing
The order below is an NHI Mgmt Group recommendation. It starts from the activities that matter most and works downward, because a complete model of everything is never finished.
- Pick the critical activities. Agree five to ten business activities with leadership, for example taking payments, running payroll or operating a plant. NIST CSF 2.0 GV.OC-01 and ID.AM-05 give the governance hook.
- Organization Mapping for those activities (D3-OM). Record the accountable owner, the teams that perform each activity and the roles they hold. Add owners for the systems and machine identities involved.
- Operational Dependency Mapping (D3-ODM). For each activity list the applications, data stores, third party services, identity providers and infrastructure it depends on, layered from activity to platform. Join this to the asset inventory and network model so dependencies resolve to real hosts and paths.
- Access Modeling (D3-AM). For each dependency, record which identities hold administrative or data access, human and non-human. Effective permissions matter more than assigned roles: include group nesting, cloud role assumption and delegated grants. See the Access Reviews Guide and Role Mining and Role Design Guide.
- Operational Risk Assessment (D3-ORA). Assess risk per activity using the model: single points of failure, identities whose compromise would stop or corrupt the activity, and dependencies with known vulnerabilities. Feed results into the risk register.
- Connect to detection and response. Tag assets and identities with the activities they support, so the SOC sees business impact on alerts and responders can prioritise.
Testing the model
- Tabletop it: take one activity, simulate the loss of one dependency or the compromise of one privileged identity, and check whether the model predicted the impact correctly.
- Reconcile access: compare D3-AM output with live entitlements from the identity provider and cloud platforms monthly; unexplained differences are findings.
- Check ownership: every identity and dependency in scope must have a current owner who confirms it at review.
- Rollback: the model is documentation, so the risk is acting on wrong data. Version it, and record the date each part was last confirmed.
Small versus large organisations
- Small: a spreadsheet of critical activities, owners, dependencies and privileged identities, reviewed twice a year, delivers most of the value.
- Large and regulated: link the architecture repository, CMDB service maps, IGA platform and risk register so the model refreshes from source systems, and use it for operational resilience mapping where regulators require it.
- Critical infrastructure and OT: extend D3-ODM to physical processes and safety functions, built with engineering.
ATT&CK techniques D3FEND relates to Operational Activity Mapping
D3FEND relates defensive and offensive techniques through shared digital artefacts. For D3-OAM the links arrive mostly through Access Modeling's artefacts (user accounts, digital identities and access control configuration), and D3FEND labels them "inferred, experimental". The table groups the entries the page lists, using ATT&CK v20 IDs.
| ATT&CK v20 technique | How the model helps |
|---|---|
| T1078.001 Default Accounts, T1078.002 Domain Accounts, T1078.003 Local Accounts, T1078.004 Cloud Accounts | Known access per identity makes use outside its activity stand out |
| T1098.002 Additional Email Delegate Permissions, T1098.003 Additional Cloud Roles | Permission changes compared with the access model |
| T1136.001 Local Account, T1136.002 Domain Account, T1136.003 Cloud Account | New accounts without an owner or activity are anomalies |
| T1087.001 Local Account, T1087.002 Domain Account, T1087.004 Cloud Account; T1615 Group Policy Discovery | Shows what an attacker can learn, and which discovery matters most |
| T1548.001 Setuid and Setgid, T1548.005 Temporary Elevated Cloud Access, T1134.005 SID-History Injection | Elevation paths visible in the access model |
| T1556.009 Conditional Access Policies, T1484 Domain or Tenant Policy Modification, T1222 File and Directory Permissions Modification | Policy changes compared with the modelled baseline |
| T1552.006 Group Policy Preferences | Credentials stored in policy objects |
| T1531 Account Access Removal | Dependency model shows which activities stop when key accounts are locked out |
See the MITRE ATT&CK T1078 Valid Accounts Guide, MITRE ATT&CK T1098 Account Manipulation Guide and MITRE ATT&CK T1136 Create Account Guide for those techniques in depth.
Where identity fits
Access Modeling is an identity technique by definition, and its definition explicitly includes systems as identities. In most estates service accounts, workload identities, API keys and OAuth integrations outnumber people, and they are the identities most often missing from organisation and access models because no HR record creates them. Give every non-human identity in the model an accountable human owner and an activity it supports; an identity that cannot be tied to an activity is a removal candidate. See How to assign owners to orphaned service accounts and NHI Inventory Reconciliation.
Detection and measurement
Once activities, dependencies and access are linked, alerts can carry business context: a privileged change on an identity that supports payments ranks above the same change on a test system. Useful detections include access granted outside the modelled roles for an activity, new identities with access to critical dependencies but no owner, and policy changes on identity providers that critical activities depend on.
Metrics we suggest at NHI Mgmt Group (example targets are illustrations, not standards):
- Activity coverage: share of agreed critical activities with a complete owner, dependency and access model.
- Ownership coverage: share of in-scope identities, human and non-human, with a current accountable owner (example target 100 per cent for privileged identities).
- Model freshness: share of model entries confirmed in the last six months.
- Access drift: entitlements found live but absent from the access model, per review.
- Alert context rate: share of high severity alerts that carry the business activity affected.
- Tabletop accuracy: share of tabletop scenarios where the model predicted the impact correctly.
Framework mapping
| Framework | Reference | Link to D3-OAM |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01, GV.OC-05 | Mission understood; outcomes and services the organisation depends on understood |
| NIST CSF 2.0 | ID.AM-05, ID.RA-04 | Assets prioritised by mission impact; impacts and likelihoods recorded |
| NIST CSF 2.0 | PR.AA-05 | Access permissions defined, managed and reviewed (Access Modeling) |
| NIST SP 800-53 Rev. 5 | PM-11 Mission and Business Process Definition, RA-9 Criticality Analysis, CP-2 Contingency Plan | Activities, criticality and dependencies |
| NIST SP 800-53 Rev. 5 | AC-2 Account Management, AC-6 Least Privilege, RA-3 Risk Assessment | Access Modeling and Operational Risk Assessment |
| MITRE D3FEND | Model tactic | The tactic D3-OAM sits in |
Common failure patterns
- Modelling everything at once. Mapping every process before any is useful stalls the programme; start with critical activities.
- Continuity and security models kept apart. Two teams map the same dependencies differently and neither is trusted.
- Assigned roles instead of effective access. Group nesting and cloud role assumption hide the real permissions.
- Machine identities left out. Service accounts and integrations carry most privileged access and are missing from HR driven models.
- Identity providers not listed as dependencies. Every activity depends on authentication, so an identity provider outage or compromise affects all of them.
- A model nobody uses. If alerts and incident runbooks do not reference the model, it decays.
Practitioner checklist
- Agree a short list of critical business activities with leadership.
- Record owners, teams and roles for each activity, including owners for machine identities.
- Map dependencies from activity to application, service, identity provider and infrastructure.
- Model effective access to each critical dependency for human and non-human identities.
- Assess risk per activity and feed it into the risk register.
- Tag assets and identities with activities so alerts carry business context.
- Reconcile the access model with live entitlements monthly.
- Tabletop one activity per quarter to test the model.
Standards and references
- MITRE D3FEND: Operational Activity Mapping
- MITRE D3FEND: Access Modeling
- MITRE D3FEND: Operational Dependency Mapping
- Object Management Group: Unified Architecture Framework (UAF)
- IETF: RFC 7642 System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: MITRE D3FEND Guide · Crown jewels analysis · Access Reviews Guide · Entitlement Catalogue Guide · MITRE D3FEND Access Policy Administration Implementation Guide