> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# NFC verification warnings

> Every warning Didit's NFC module emits — skipped chip read, unverified chip, OCR/chip mismatch, certificate revoked or expired — with cause, severity, and remediation.

export const WarningTypes = () => <div style={{
  display: "flex",
  flexDirection: "column",
  gap: "12px",
  margin: "16px 0"
}}>
    {WARNING_TYPES.map(w => <div key={w.type} style={{
  display: "flex",
  alignItems: "flex-start",
  gap: "12px",
  padding: "12px 16px",
  borderRadius: "8px",
  background: w.bg
}}>
        <span style={{
  fontSize: "16px",
  lineHeight: "24px"
}}>{w.icon}</span>
        <div>
          <div style={{
  fontWeight: 600,
  color: w.color,
  marginBottom: "2px"
}}>
            <code style={{
  background: "transparent",
  color: w.color,
  fontWeight: 600,
  padding: 0
}}>
              {w.type}
            </code>
          </div>
          <div style={{
  fontSize: "14px",
  lineHeight: "20px",
  color: "#374151"
}}>
            {w.description}
          </div>
        </div>
      </div>)}
  </div>;

## Overview

Warnings on the NFC report flag every condition Didit observed while reading and validating the chip. They land in the `warnings[]` array on each item of `nfc_verifications[]` (see [NFC report](/core-technology/nfc-verification/report-nfc-verification)), with `feature` set to `"NFC"`. Each entry follows the shared [warning object](/reference/data-models#warning-object) shape: `feature`, `risk`, `additional_data`, `log_type`, `short_description`, `long_description`, `node_id`.

Every warning has three layers:

1. **The `risk` code** — a stable identifier you can match on in your code (the codes listed below).
2. **The `log_type`** — one of `information`, `warning`, or `error`. It is derived from the action your workflow configures for that risk: **No action** → `information`, **Review** → `warning`, **Decline** → `error`.
3. **The decision impact** — the same configured action also drives the NFC report's `status`: a Review action moves it to `In Review`, a Decline action to `Declined`.

Three NFC risks are configurable this way (`SKIPPED_NFC_VALIDATION`, `NFC_CHIP_NOT_VERIFIED`, `NFC_AND_OCR_DATA_NOT_SAME`). The two certificate risks (`DSC_CERTIFICATE_REVOKED`, `DSC_CERTIFICATE_EXPIRED`) are **informational only**: they always carry `log_type: "information"` and never change the NFC status by themselves.

The full set of risk codes the NFC module produces is below. No other NFC risk codes exist.

## Warnings produced

| `risk`                      | Cause                                                                                                                                                                                                                                                         | Severity (`log_type`)                                                                                                                                   | Affects status?                               | Remediation                                                                                                                                                                                                                            |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `SKIPPED_NFC_VALIDATION`    | The chip read was skipped — the workflow allows skipping (`allow_nfc_skip`) and the user tapped skip because the device did not support NFC or could not align the chip.                                                                                      | Follows the **skip NFC action** setting (`skip_nfc_action`): information / warning / error.                                                             | Configurable — No action, Review, or Decline. | If your policy requires NFC, set the skip action to Decline (or disallow skipping entirely) and instruct the user to retry from an NFC-capable device. Otherwise leave it at No action to fall back to OCR-only verification.          |
| `NFC_CHIP_NOT_VERIFIED`     | The chip was read but failed cryptographic verification: `dg_integrity` or `sod_integrity` is `false`. This usually means the issuing country's CSCA could not validate the SOD signature, the DSC is revoked or expired, or a Data Group hash did not match. | Follows the **unverified chip action** setting (`unverified_chip_action`).                                                                              | Configurable — No action, Review, or Decline. | Older travel documents often trigger this without indicating fraud. Decide your tolerance per market; Review is a common setting. Inspect `authenticity` and `certificate_summary.validation` on the report to see which check failed. |
| `NFC_AND_OCR_DATA_NOT_SAME` | The MRZ read from the chip does not match the MRZ OCR'd from the visible side of the document (compared after normalization, ignoring `<` filler). Strong tampering signal.                                                                                   | Follows the **data inconsistency action** setting (`inconsistent_data_action`) — the same setting that governs ID-verification data-consistency checks. | Configurable — No action, Review, or Decline. | Treat as tampering unless proven otherwise; Decline is the typical setting. The `additional_data` payload includes the OCR MRZ lines (`ocr_mrz`, array) and the chip MRZ (`nfc_mrz`, single string) for manual comparison.             |
| `DSC_CERTIFICATE_REVOKED`   | The Document Signer Certificate that signed this chip appears in the issuing country's Certificate Revocation List (CRL).                                                                                                                                     | Always `information`.                                                                                                                                   | No — never changes the NFC status by itself.  | Strong signal that the signing key may have been compromised; route these sessions to manual review via your own logic if needed. Note the chip will usually also fire `NFC_CHIP_NOT_VERIFIED`, which is configurable.                 |
| `DSC_CERTIFICATE_EXPIRED`   | The DSC's validity window has passed (`certificate_summary.validation.dsc_expired` is `true`).                                                                                                                                                                | Always `information`.                                                                                                                                   | No — never changes the NFC status by itself.  | Common with older documents. As with revocation, an expired DSC also fails full SOD validation, so `NFC_CHIP_NOT_VERIFIED` fires alongside it and carries your configured action.                                                      |

<Note>
  `SKIPPED_NFC_VALIDATION` and `NFC_CHIP_NOT_VERIFIED` are mutually exclusive: the unverified-chip warning is only evaluated when the chip read was not skipped.
</Note>

## Exact description strings

The API returns these exact `short_description` and `long_description` strings for each risk:

| `risk`                      | `short_description`                 | `long_description`                                                                                                                                                                                            |
| --------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `SKIPPED_NFC_VALIDATION`    | Skipped NFC Validation              | The Near Field Communication (NFC) chip validation process was not completed, potentially due to technical issues or lack of NFC support.                                                                     |
| `NFC_CHIP_NOT_VERIFIED`     | NFC chip not verified               | The Near Field Communication (NFC) chip was not verified, potentially due to missing certificate to verify the signature of the chip, or the chip is designed to not be verified.                             |
| `NFC_AND_OCR_DATA_NOT_SAME` | NFC and OCR data not same           | The Near Field Communication (NFC) chip data and the OCR data don't match, indicating potential document tampering or data inconsistency.                                                                     |
| `DSC_CERTIFICATE_REVOKED`   | Document Signer Certificate revoked | The Document Signer Certificate (DSC) used to sign the ePassport chip data has been revoked by the issuing country's Certificate Revocation List (CRL), indicating the signing key may have been compromised. |
| `DSC_CERTIFICATE_EXPIRED`   | Document Signer Certificate expired | The Document Signer Certificate (DSC) used to sign the ePassport chip data has expired, meaning the certificate's validity period has passed.                                                                 |

## Configuration

Three workflow settings control how NFC warnings route. Each can be set to **No action**, **Review**, or **Decline**:

1. **Skip NFC action** (`skip_nfc_action`) — applies to `SKIPPED_NFC_VALIDATION`. Skipping is only offered to users when `allow_nfc_skip` is enabled.
2. **Unverified chip action** (`unverified_chip_action`) — applies to `NFC_CHIP_NOT_VERIFIED`.
3. **Data inconsistency action** (`inconsistent_data_action`) — applies to `NFC_AND_OCR_DATA_NOT_SAME`. This is the same data-inconsistency setting used by ID verification.

The two `DSC_CERTIFICATE_*` risks have no action setting — they are always informational.

## Examples

### In Review — chip could not be verified

```json theme={null}
{
  "warnings": [
  {
    "feature": "NFC",
    "risk": "NFC_CHIP_NOT_VERIFIED",
    "additional_data": null,
    "log_type": "warning",
    "short_description": "NFC chip not verified",
    "long_description": "The Near Field Communication (NFC) chip was not verified, potentially due to missing certificate to verify the signature of the chip, or the chip is designed to not be verified.",
    "node_id": "nfc_primary"
  },
  {
    "feature": "NFC",
    "risk": "DSC_CERTIFICATE_EXPIRED",
    "additional_data": null,
    "log_type": "information",
    "short_description": "Document Signer Certificate expired",
    "long_description": "The Document Signer Certificate (DSC) used to sign the ePassport chip data has expired, meaning the certificate's validity period has passed.",
    "node_id": "nfc_primary"
  }
]
}
```

Here the unverified-chip action is set to Review, so `NFC_CHIP_NOT_VERIFIED` carries `log_type: "warning"` and the NFC report's status is `In Review`. The expired-DSC entry is purely informational.

### Declined — chip / OCR mismatch

```json theme={null}
{
  "warnings": [
  {
    "feature": "NFC",
    "risk": "NFC_AND_OCR_DATA_NOT_SAME",
    "additional_data": {
      "ocr_mrz": ["P<ESPDOE<<JOHN<<<<<<<<<<<<<<<<<<<<<<<<<<<<<", "AAB000123ESP9005154M3001017<<<<<<<<<<<<<<04"],
      "nfc_mrz": "P<ESPDOE<<JOHN<<<<<<<<<<<<<<<<<<<<<<<<<<<<<AAB000254ESP9005154M3001017<<<<<<<<<<<<<<06"
    },
    "log_type": "error",
    "short_description": "NFC and OCR data not same",
    "long_description": "The Near Field Communication (NFC) chip data and the OCR data don't match, indicating potential document tampering or data inconsistency.",
    "node_id": "nfc_primary"
  }
]
}
```

Here the data-inconsistency action is set to Decline, so the warning carries `log_type: "error"` and the NFC report's status is `Declined`. Note that `ocr_mrz` is an array of MRZ lines while `nfc_mrz` is the chip's single concatenated MRZ string.

## Warning types

Each risk is assigned a severity based on your application's configuration. The three severities are:

<WarningTypes />

## Related

* [NFC report](/core-technology/nfc-verification/report-nfc-verification) — full report schema and statuses.
* [Webhooks](/integration/webhooks) — `status.updated` fires on session status changes; the decision payload (including NFC warnings) is attached when the session reaches Approved, Declined, In Review, or Abandoned.
* [Data models — NFC verification](/reference/data-models#nfc-verification) — canonical field-by-field schema.
* [Data models — Warning object](/reference/data-models#warning-object) — the shape of every entry in `warnings[]`.