This glossary defines the main concepts, acronyms, and entities referenced throughout the SmartCMS documentation.
All terms are derived from the SmartCMS Technical White Paper.
A set of mechanisms exposed by SmartCMS to allow external systems to interact with the platform using REST or JSON-over-HTTP services. Supports operations on requests, devices, certificates, operators, offices, and more.
The subsystem responsible for tracking every significant operation in SmartCMS.
Logs include timestamps, operator IDs, action types, and data snapshots.
Exportable in CSV, JSON, and XML; can be digitally signed with HSM.
One of the three provisioning flows supported by SmartCMS.
Used for mass production of devices via the SmartCMS Batch Station, including certificate batch issuance (if supported by the CA).
Operator profile responsible for centralized device production in bureau workflows. Tasks include personalization, packaging, verification, and shipping.
An entity that issues digital certificates. SmartCMS can interact with multiple CAs through the CA Service Gateway. Examples include InfoCert, PosteCOM, Actalis, Intesa, ArubaPEC.
A SmartCMS module that decouples the core system from CA-specific APIs. Allows simultaneous connection to multiple CA backends for issuance, suspension, revocation, renewal.
The full lifecycle of certificates, including issuance, suspension, reactivation, revocation, and renewal. Managed entirely within SmartCMS.
A template defining the characteristics of a certificate (key usage, policies, validity, etc.). Selectable by operators during request entry.
Operator responsible for token personalization, certificate import, revocation actions, and other advanced tasks. Typically operates within a specific office.
The process of personalizing a device graphically (visual printing), electronically (keys/certificates), and at data level (files, metadata).
Special codes used to revoke or disable tokens in case of theft, loss or compromise. Generated via strong RNG and stored encrypted.
The process by which a user is registered, identified, and associated with a cryptographic credential. Might include face‑to‑face recognition, request creation, personalization, and issuance.
Structured test data (JSON, XML, YAML) that can be loaded into SmartCMS to support testing, debugging, and development. Exportable from a running system.
Operator role responsible for lifecycle actions such as suspension, reactivation, and revocation. Has visibility over all issued devices.
Secure cryptographic hardware used for strong RNG, certificate operations, and digital signature of audit exports. Integrated within SmartCMS where required.
A provisioning flow where device personalization and certificate download occur during a live operator session.
Design pattern used in SmartCMS allowing modules to be replaced or extended without recompiling the system. Dependencies are injected via configuration.
Public and private key generated during device personalization or remote enrolment. Used for signing, authentication, and encryption.
SmartCMS’s ability to manage complete lifecycle of devices (smart cards, tokens) and certificates (issue, suspend, renew, revoke).
Automated database schema evolution system. Supports forward/backward migrations, transactional safety, and automated rollout during updates.
Architecture allowing independent modules to be added, removed, or replaced without impacting system core.
A system user with a specific role (RO, DO, BO, SA, HD, AO). Each operator operates within a specific visibility scope (office, division, organization).
Three hierarchical levels used to model complex PKI ecosystems. Offices are the operational units where enrolments and issuance occur.
A highly customizable data model for defining personal attributes belonging to subscribers and other system entities. Accepts new attributes with validation rules.
Secret codes used to authenticate device holders and recover access. Managed securely through SmartCMS secret code subsystem.
Operator responsible for face‑to‑face identification, enrolment data entry, and device delivery. Visibility limited to requests they handled.
Permanent invalidation of a certificate. Supported individually or in batch and recorded in audit logs.
PIN/PUK and other confidential tokens associated with devices. Stored encrypted in DB. Generated using hardware RNG (smart cards or HSM).
Provisioning mode where user initializes and activates their device via self‑service portal. No operator involvement needed.
Web portal used by end users (Token Holders) to perform certificate renewal, suspension, PIN reset, and virtual token requests.
Bit4id subsystem integrated with SmartCMS to log administrator access to archives and logical systems for compliance purposes.
End user of the digital identity device. Can access self-service portal for lifecycle actions such as renewal, suspension, PIN reset.
Electronic initialization of a smart card or USB token, including key generation, certificate import, and security data loading.
Bit4id’s unified middleware for managing local and remote certificates, signing operations, PKCS#11/CSP/CryptoTokenKit interfaces, and secure authentication. A core component of SmartCMS.
The engine beneath UKC that provides card drivers, PKCS#11 libraries, CSP/KSP modules, PC/SC communication, plugin architecture, and certificate store integration.
This glossary provides all terminology required to understand SmartCMS architecture, workflows, operator roles, cryptographic processes, and administrative controls.
Each term reflects the definitions provided in the official SmartCMS white paper.