Understanding the CIP-X-101 Standard
A comprehensive guide to the Asset Registry standard for cryptographic device inventory management.
Purpose of the Asset Registry
CIP-X-101 v0.2.0
The Asset Registry is the authoritative inventory of every device that stores, manages, or facilitates access to cryptographic assets. Every security control in the CIP-X framework depends on this registry. If a device is not registered, it cannot be secured, audited, or controlled.
Core Principle: You cannot protect what you do not know exists. The registry serves as the single source of truth for every cryptographic device across your organization, spanning physical data centers, cloud environments, and hybrid deployments.
Data Model
Each registered device maps to a database record with these fields. The device_id serves as the primary key and is referenced across all other CIP-X standards.
| Field | Type | Description | Example |
|---|---|---|---|
device_id | string (PK) | Unique identifier used across all systems | hsm-prod-us-east-001 |
device_name | string | Human-readable name for operational reference | Validator Primary US-East |
serial_number | string | Manufacturer-assigned serial number | TH-2024-00127 |
model | string | Exact model designation from manufacturer | Luna HSM 7 |
manufacturer | string | Device manufacturer or cloud provider | Thales |
device_type | enum | Functional category of the device | HSM | Validator | RPC Node | Signing Server |
physical_location | string | Data center, rack position, and unit | Equinix DC5, Ashburn VA, Rack 12A, U24 |
jurisdiction | string | Legal jurisdiction governing the device | United States, Virginia |
owner | string | Team responsible for the device | Security Operations |
manager | string | Individual accountable for the device | Alice Chen |
status | enum | Current operational state | Active | Maintenance | Retired | Decommissioned |
tier | enum | Security classification assigned by CIP-X-103 | Tier 1 | Tier 2 | Tier 3 |
control_path | json | Full chain of control from device to personnel | {host_system, physical_container, data_center, ...} |
last_verified | timestamp | Date of most recent physical/logical verification | 2026-02-06T10:30:00Z |
next_verification | timestamp | Scheduled date for next required verification | 2026-03-06T10:30:00Z |
Device Types
The registry classifies every device into one of four functional categories. Each type has distinct security requirements and operational characteristics.
HSM
Hardware Security Module
Dedicated tamper-resistant hardware for cryptographic key storage and operations. HSMs provide the highest level of key protection and are typically used for root keys and high-value signing operations.
Validator
Blockchain Validator Node
Servers that participate in blockchain consensus by proposing and attesting to blocks. Validators hold staking keys and must maintain high uptime to avoid slashing penalties.
RPC Node
Remote Procedure Call Node
Infrastructure nodes that serve blockchain data to applications via JSON-RPC APIs. They maintain a full copy of the chain state and process read/write requests.
Signing Server
Transaction Signing Server
Specialized servers that manage signing workflows, applying policy checks before authorizing cryptographic signatures. They sit between applications and HSMs to enforce business logic.
Tier Classification
Every device is assigned a tier based on CIP-X-103. The tier determines verification frequency, physical security requirements, and access controls.
Critical
Devices that directly custody, sign, or authorize cryptographic operations involving high-value assets. Compromise of a Tier 1 device could result in immediate, irreversible loss of funds.
Required Controls
- Tamper-evident physical enclosures
- Biometric + badge access
- Dedicated network VLANs
- 24/7 monitoring with automated alerts
- Monthly verification cycles
Important
Devices that support critical operations but do not directly hold keys. Compromise could disrupt service or expose sensitive data, but does not directly enable asset theft.
Required Controls
- Locked cabinet or cage
- Badge-only physical access
- Segmented network VLANs
- Business-hours monitoring
- Quarterly verification cycles
Standard
Non-production devices used for testing, development, or staging. These devices do not interact with mainnet assets and operate in isolated environments.
Required Controls
- Standard rack placement
- Badge access to facility
- Isolated test network VLANs
- Standard logging
- Semi-annual verification cycles
Device Statuses
Every device has exactly one operational status at any given time. Status transitions are logged and auditable.
Device is fully operational, connected to the network, and performing its designated function. All security controls are in place and verified.
Device is temporarily taken offline for firmware updates, hardware repairs, or scheduled maintenance. Security controls remain enforced during this period.
Device has been removed from active duty but has not yet been physically decommissioned. Keys may still reside on the device pending secure erasure procedures.
Device has been securely wiped, physically disconnected, and removed from the network. All cryptographic material has been destroyed per the key destruction protocol.
Verification Schedule
Each device must be periodically verified to confirm its physical location, operational status, and security controls match the registry record. The verification frequency is determined by the device tier:
| Tier | Frequency | Overdue Threshold |
|---|---|---|
| Tier 1 | Every 30 days | next_verification < now() |
| Tier 2 | Every 90 days | next_verification < now() |
| Tier 3 | Every 180 days | next_verification < now() |
Warning: Overdue devices are flagged on the dashboard with a red indicator. An overdue verification means the registry can no longer guarantee that the physical and logical state of the device matches its record.
Control Path
The control_path field: records the complete chain of physical and logical control from the device to the personnel who can access it. Stored as a JSON object with five components:
host_systemWhether the device runs on bare-metal, a VM, or a cloud instance (e.g., EC2)
physical_containerThe physical enclosure type: tamper-evident cage, locked cabinet, or standard rack
data_centerThe specific facility where the device is located
network_pathNetwork segmentation: dedicated VLAN, VPC peering, or public internet exposure
personnel_accessRequired authentication to physically reach the device: biometric, badge, IAM role, etc.