Crown jewels analysis: find, map and protect your most critical assets

Most organisations cannot say which few systems, data stores and credentials would stop the business if they failed or were stolen, so they spread protection evenly and leave the critical ones no better defended than the rest. Crown jewels analysis (CJA) is the discipline of finding those assets by working down from mission objectives to the cyber assets they depend on. This guide explains the MITRE Crown Jewels Analysis method, how it relates to business impact analysis (BIA) in NIST IR 8286D, how to map dependencies, how to bring identities and non-human identities (NHIs) that reach crown jewels into scope, and how to handle exposure and aggregation risk. It is for security architects, risk managers and identity teams who need a defensible list of what to protect first.

Key takeaways

• Start from the mission, not the asset list. MITRE's CJA decomposes objectives into tasks, functions and cyber assets, then scores how losing each child affects its parent.
• A crown jewel is defined by impact of failure. MITRE defines it as an asset whose failure, or failure to perform as intended, causes a mission objective to fail.
• Dependencies hide the real jewels. A router, directory or backup system often matters more than the application everyone names, because many critical functions depend on it.
• Identities that reach crown jewels are part of the crown jewel. Service accounts, API keys, CI/CD tokens and admin roles that can read, change or destroy a crown jewel inherit its criticality.
• Watch aggregation. One backup platform, identity provider or secrets vault that holds many crown jewels concentrates risk and needs protection matching the sum, not the average.

What crown jewels analysis is

MITRE describes CJA as a process and toolset for identifying the cyber assets most critical to an organisation's mission, using a mission-decomposition approach that surfaces dependencies less rigorous methods miss. The premise is economic: it is not cost-effective to make every asset survive a determined attack, so the organisation identifies the assets that must keep operating and focuses on them. MITRE developed it for defence programmes and has published versions for healthcare and industrial control systems.

MITRE's ICS publication defines a crown jewel as a device or component whose failure, or failure to perform as intended, can cause mission failure, and scores impact on four levels: Total Mission Failure, Significant Degradation, Partial Capability Loss, and Negligible or No Loss. Note what the definition includes: integrity failures ("failure to perform as intended"), not only outages. A payments ledger that keeps running but records wrong balances is a crown jewel failure.

CJA compared with related methods

See the Business Impact Analysis Template for the BIA side and the NIST SP 800-30 Risk Assessment Guide for scenario assessment.

The MITRE CJA method step by step

MITRE's healthcare CJA publication sets out a five-step process and a four-tier model. The tiers and matrices are the core of the method.

The five steps, using MITRE's names:

1. Collect data and build initial model: agree scope with senior management and draft the objectives and the objective-to-task matrix.
2. Validate initial model: confirm the top two matrices and draft the task-to-function and function-to-asset matrices.
3. Query SMEs for scores and relationships: subject matter experts score every parent-child dependency, producing dependency maps.
4. Perform impact analysis and identify crown jewels: the model fails each cyber asset in turn and propagates the impact upward; assets whose failure causes an objective to fail are the crown jewels.
5. Conduct what-if analyses and present findings: test options (redundancy, alternative processes) and support resource decisions.

Scoring dependencies

In the healthcare version, each dependency in tiers 2 to 4 gets one of four criticality levels with default scores: HIGH (parent fails) 95, MEDIUM (parent degraded even with a workaround) 70, LOW (a documented, trained workaround is required) 30, NONE 0. Objectives are weighted with the analytic hierarchy process (AHP) and the lower matrices use quality function deployment (QFD); the ICS version also uses failure modes and effects analysis (FMEA). Reading down a dependency map shows what an objective depends on; reading up shows what a failed asset affects. You do not need MITRE's tool to apply the logic: a spreadsheet with the four matrices and a simple propagation rule (an asset is a crown jewel candidate if it has a HIGH path to any objective) gets most organisations most of the value.

Business impact, criticality and sensitivity

NIST IR 8286D (Update 1, final, February 2025) extends BIA beyond availability to any type of loss and provides useful definitions for scoring. It separates criticality, harm from loss of availability, from sensitivity, harm from loss of confidentiality or integrity. It also states that supporting assets inherit the criticality or priority of the functions they support, and that criticality should consider interdependencies, giving the example of a network router that has significant enterprise importance because it enables a vital sales website.

Use both dimensions. MITRE CJA as published is mainly framed around failure and degradation. A customer data warehouse may have low criticality (the business runs for days without it) and very high sensitivity (a leak triggers regulatory notification and lasting damage). Treat an asset as a crown jewel if it scores high on either dimension, and record which, because the controls differ: resilience and recovery for criticality, access control, encryption and monitoring for sensitivity.

• Financial: revenue loss per day of outage, fines, contractual penalties.
• Mission and operational: services that stop, safety impact, regulatory reporting deadlines missed.
• Reputational and legal: notification duties, customer trust, litigation. NIST IR 8286D notes composite results express exposure in financial, mission and reputational terms in the enterprise risk profile.

Dependency mapping in practice

The analysis is only as good as the dependency map, and MITRE's ICS publication stresses that no single person usually understands all dependencies, so SMEs from mission, business, operations and security roles must contribute. Practical sources for the bottom two tiers:

• Asset inventory and CMDB: systems and owners. See the Asset Inventory and CMDB Security Guide.
• Network and data flow diagrams: NIST CSF 2.0 ID.AM-03 expects representations of authorised network communication and data flows; these show which infrastructure carries each function.
• Shared platform dependencies: identity providers, directories, DNS, certificate authorities, key management, backup, logging, CI/CD and hypervisors. These rarely appear in an application owner's view and are often the real crown jewels.
• Third parties: SaaS platforms, managed service providers and payment processors that perform a function. A supplier can be a crown jewel dependency even though you do not own the asset.
• Recovery dependencies: what you need to restore the crown jewel (backup platform, offline credentials, golden images). An asset that cannot be recovered without a second asset makes that second asset critical too.

Identities and NHIs that reach crown jewels

Crown jewel lists usually stop at systems and data. Attackers do not: they look for the account, token or key that can reach the system. Extend the fourth tier, or add a fifth, listing every identity with privileged or data-level access to each crown jewel, then apply the NIST IR 8286D rule that supporting assets inherit the criticality of what they support.

Two breaches show why. In the LastPass breach, cloud access keys and backup decryption keys held in one engineer's vault gave attackers the customer vault backups, so the identity and its secrets were effectively part of the crown jewel. In the Change Healthcare breach, a remote-access login without MFA led to systems whose outage stopped claims processing across US healthcare for weeks. Use attack path analysis (see the Identity Attack Paths Guide) to test whether ordinary accounts can reach crown jewels in a few hops.

Exposure factor and aggregation risk

Exposure factor: in quantitative risk analysis, the exposure factor is the proportion of an asset's value expected to be lost in a given scenario, and single loss expectancy is asset value multiplied by exposure factor. It is useful in CJA because it separates "how important is this asset" from "how much of that importance this scenario destroys". A ransomware scenario on an ERP system with tested immutable backups might have a modest exposure factor; the same scenario without recoverable backups approaches total loss. Record exposure factor per scenario, not per asset, and revisit it after controls change.

Aggregation risk: NIST's glossary defines aggregation as the consolidation of similar or related information. In crown jewel terms, aggregation risk is what happens when many crown jewels, or many copies of crown jewel data, depend on one component. Common examples:

• Identity providers and directories: every crown jewel that uses SSO depends on the IdP. Its compromise is the compromise of all of them.
• Backup platforms: they hold copies of every crown jewel's data and are also the recovery path for each.
• Secrets vaults and key management: one vault holding keys for many systems. Aggregation is the price of good secrets management, so the vault's own protection must reflect the sum.
• Data lakes and analytics platforms: they combine data sets that are individually low sensitivity into something high sensitivity.
• Management planes: hypervisor managers, cloud organisation admin, MDM and RMM tools that can change many crown jewels at once.

Score aggregators by summing (or taking the maximum of) the impacts of what they hold, not by their own business function, and add them to the crown jewel list explicitly. NIST IR 8286D describes aggregating lower-level risk registers so leaders can see aggregate impact; aggregation points are where that view matters most.

How to run a CJA: a practical rollout

1. Get a sponsor and scope. One business unit or service first. Agree three to six objectives with senior management and weight them.
2. Build tiers 1 and 2 in workshops with business SMEs, then validate with the sponsor.
3. Build tiers 3 and 4 with IT and operations, pulling from the CMDB, architecture diagrams and cloud inventories. Add shared platforms and third parties explicitly.
4. Score dependencies on a four-level scale and run the propagation: which assets have a HIGH path to an objective? Add sensitivity scoring for confidentiality and integrity.
5. Add the identity tier: for each candidate crown jewel, list identities with admin or data access, including NHIs, and their credentials.
6. Identify aggregators and score them on what they hold.
7. Test with what-if scenarios: ransomware on the backup platform, IdP compromise, key theft from CI/CD. Use them to set exposure factors.
8. Turn results into control requirements (see the table below), owners and dates, and record them in the BIA and risk registers.
9. Repeat annually and after major change (mergers, new platforms, cloud migrations). Small organisations can run a one-day workshop with a spreadsheet; large ones run it per business unit and reconcile shared dependencies centrally.

From crown jewels to controls and monitoring

Metrics that show the programme is working:

• Percentage of crown jewels with a named business and technical owner and a date of last review.
• Number of identities (human and non-human) with standing privileged access to each crown jewel, trending down.
• Percentage of crown jewels with a successful restore test in the last 12 months.
• Percentage of crown jewels whose NHIs use federated or managed credentials rather than static secrets.
• Attack path count: identities that can reach a crown jewel within three hops from an ordinary user.

Common failure patterns

• Listing applications, missing platforms: the IdP, backup system and CI/CD are left off because no business owner names them, though every crown jewel depends on them.
• Availability only: scoring only outage impact and missing high-sensitivity data stores whose theft is the real harm.
• Ignoring the identities: hardening the database while a broadly scoped service account key sits in a pipeline, the pattern in the LastPass breach.
• Too many crown jewels: if half the estate is a crown jewel, nothing is prioritised. Recalibrate weights until the list is short enough to fund.
• A one-off workshop: results go stale within a year as architecture changes. Tie review to change management.
• No link to the risk register: the analysis never turns into owned, funded actions.

Framework mapping

Practitioner checklist

• Agree three to six weighted mission or business objectives with senior management.
• Decompose objectives into tasks, functions and cyber assets, and score each dependency on a four-level scale.
• Score both criticality (availability) and sensitivity (confidentiality and integrity).
• Add shared platforms, recovery dependencies and third parties to the asset tier.
• List every human and non-human identity with privileged or data access to each crown jewel.
• Identify aggregators (IdP, backup, vault, data lake, management planes) and score them on what they hold.
• Run what-if scenarios and record exposure factors per scenario.
• Turn results into access, credential, resilience and detection requirements with owners and dates.
• Record outputs in the BIA and risk registers and review annually and after major change.

Standards and references

• MITRE: Crown Jewels Analysis
• MITRE: Crown Jewels Analysis for Healthcare
• MITRE: Crown Jewels Analysis for Industrial Control Systems
• NIST: IR 8286D Using Business Impact Analysis to Inform Risk Prioritization and Response
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• NIST: Glossary, aggregation

Related NHI Mgmt Group resources: Business Impact Analysis Template · Identity Attack Paths Guide · Asset Inventory and CMDB Security Guide · NIST SP 800-30 Risk Assessment Guide