# Policies A **policy** in Axiad Mesh is a set of rules that Mesh evaluates your identities and assets against. The most developed policies today are **cryptographic compliance policies** — the rules behind post-quantum readiness and the *PQC noncompliant* risk you see in the [PQC dashboard](../user-guide/pqc-dashboard.md). ## What a crypto compliance policy contains A compliance policy is a named rule set that targets a class of cryptographic material — certificates, keys, or the software that uses them. Inside it, there is one rule per cryptographic algorithm, and each rule places that algorithm on a four-level scale: | Level | Meaning | Effect on risk | | --- | --- | --- | | **Preferred** | The algorithm you want assets to use. | Compliant. | | **Acceptable** | Allowed, but not the target state. | Compliant. | | **Deprecated** | On its way out; should be migrated. | Raises a medium-severity risk. | | **Prohibited** | Must not be used. | Raises a critical-severity risk. | A rule can also pin the acceptable key sizes or curves for an algorithm, so a policy can say "this algorithm, but only at this strength." If an asset uses an algorithm a policy hasn't approved, Mesh treats that fail-closed — as a violation — rather than assuming it's fine. ### Deadlines Policies express the *when* of a migration in two places: - **Per-algorithm deadline** — an algorithm can carry a date after which it flips from a warning to a violation, so you get lead time before a "deprecated" algorithm becomes "prohibited." - **Program deadline** — a whole framework (see below) can carry an overall transition window. Together these are what let a post-quantum policy say, for example, that classical public-key algorithms are acceptable today but must be gone by a target year, while post-quantum algorithms are already preferred. ## How policies become risks A compliance engine continuously evaluates every certificate, key, software, and machine asset against all enabled policies. For each asset it reads the algorithms in use and checks them against every rule. When an asset uses a deprecated or prohibited algorithm, Mesh raises a **policy-based risk** — the *PQC noncompliant* tag — on that asset, listing the offending attributes and naming the policy that triggered it. The severity follows the algorithm's level. When an asset stops violating a policy — after remediation, or after a rescan picks up a changed attribute — Mesh resolves the risk on its own. Evaluation runs both when an asset changes and on a regular schedule, so results stay current with your [risk scores](./risk-scoring.md). ## Frameworks Policies can be grouped into a named **framework** — for example a NIST post-quantum baseline. A framework gives each asset a compliance percentage and a severity band, so you can see not just individual violations but how far along a whole standard you are. One framework is active per category at a time, so a [Program](./programs.md) or an Audit & Compliance workspace shows a single authoritative score rather than competing ones. ## Who configures policies Mesh ships a set of **default policies and frameworks** out of the box — including a post-quantum baseline — that apply to every organization. Policies are configured by Axiad: the defaults are ready to use, and custom policies for your organization are available on request. There is no self-serve policy editor in the product today, so to tailor a policy — different algorithms, different deadlines, a custom framework — contact your Axiad representative. The Mesh AI assistant can read your active policies to explain *why* a particular asset is noncompliant and which rule it tripped. ## Related concepts - [PQC dashboard](../user-guide/pqc-dashboard.md) — where policy-based risks appear on your crypto assets. - [Programs](./programs.md) — how a policy framework's progress is tracked as an initiative. - [Risk scoring](./risk-scoring.md) — how policy risks fold into an asset's score. - [Crypto agility](../use-cases/crypto-agility.md) — the end-to-end lifecycle policies sit inside.