Simple Client is the application programming interface used by C4 clients and plugins to communicate with the application server. It provides access to platform data within the assigned permission scope instead of giving those consumers direct access to the C4 SQL Server database. The server evaluates permissions before returning information or processing an operation.

This applies to both transaction calls, which retrieve or change data, and message-based operations, which route actions to another component. For example, a request for person records is filtered to the records the user may see. An operational command is evaluated before it is routed to the responsible Driver.

An application-level permission check and authentication of a communication channel are different controls. C4 evaluates permissions on the server, but internal TCP/IP and Named Pipes have separate authentication limitations. Authorization must not be used as evidence that every internal component proves its identity. Chapter 5 describes these channels individually.

C4 is an on-premises application, and each customer operates its own installation. The security review therefore includes the hosts, internal connections, database and connected systems used by that installation; it does not stop at the C4 Client connection.

Level 1 assumes a trusted internal network, no direct public-internet exposure other than a controlled gateway, a limited number of known users, and no strict compliance requirements. Its permitted deviations include more flexible authentication and certificate handling, limited internal network authentication, and no mandatory separation of test and production environments.

These are conditional allowances, not general security guarantees. The organization must confirm that the installation satisfies the Level 1 assumptions and that its reduced protection is acceptable. If the assumptions are not met, Level 2 is required.

Level 2 is required for external-network exposure, integration with corporate identity providers, multi-site or distributed deployments, regulatory or compliance requirements, handling of sensitive or regulated data, or a requirement for high availability or business continuity. These criteria apply regardless of the number of devices.

A project can therefore require Enterprise Security even when it uses one logical C4 Server and one database. Compliance with the required controls must be demonstrated for the selected release; an unresolved requirement cannot be treated as implemented solely because the project is classified as Level 2.

C4 security requirements align with OWASP security principles and risk categories. This positioning does not provide an independent assessment result or establish compliance with a particular regulation. Security approval must address the actual installation and its evidence.

For Level 2, authentication must be delegated to a corporate or enterprise-compatible identity provider using OpenID Connect (OIDC). The requirement excludes C4 Forms authentication, local password-hash verification and storage of user authentication passwords in the C4 database. C4 relies on the identity and claims supplied by the identity service.

C4 includes an OpenID Connect service that can use local Active Directory authentication. An existing compatible identity service in the customer environment can replace it. This supports centralized identity policy and advanced authentication, such as multifactor authentication, through the chosen identity provider; it is not a claim that multifactor authentication is automatically enabled in every installation.

Forms authentication is described for smaller, controlled Level 1 installations. The documented implementation uses salted PBKDF2-HMAC-SHA1 with 1,000 iterations and requires at least eight characters, including upper- and lowercase letters, a number and a special character. Passwords are not stored in plaintext. This configuration is insufficient for Level 2.

Invalid login attempts are logged and subject to progressive delays. Automation can notify an administrator about invalid attempts, and a disabled account cannot log in. Chapter 11 identifies the account-disablement and session settings that require confirmation.

Access is denied by default until an administrator grants the relevant permission. Separate permissions govern operations such as reading, adding, modifying and deleting data. The permission model can restrict access to individual records, including devices, regions, application modules and event types.

Permissions can follow organizational hierarchies and groups, allowing inheritance from a broader responsibility while retaining control at an individual record. This supports responsibilities such as a particular building or department without giving every operator unrestricted access.

C4 evaluates API requests and message permissions on the server, and filters returned records to the authenticated user's scope. The user identity comes from the authentication context rather than an identity supplied as part of the requested data operation. These checks help keep custom interfaces and plugins within the same authorization framework.

For Forms authentication, documented session behavior includes a ten-minute idle timeout, renewal with requests, and invalidation on logout or authentication-context change. The absolute session lifetime requires release-specific confirmation. These session controls do not authenticate internal channels.

Level 2 requires certificate validation, centrally enforced by system administrators through operating-system or domain policy. Validation can use a trusted Certification Authority, a certificate thumbprint, or public-key validation (SPKI). Invalid or untrusted certificates must cause the connection to be rejected, and users must not be able to weaken the policy.

Level 2 production certificates must be issued by a trusted internal or public Certification Authority. Self-signed certificates, disabled validation, acceptance of any certificate and insecure user-defined validation strategies are not permitted. Supported secure TLS protocols and strong cipher suites are required. The enabled protocol versions and cipher inventory must be confirmed for the deployed release.

A self-signed certificate may be generated during setup for initial installation or testing. Level 1 permits more flexible validation under its controlled-environment assumptions, but acceptance of any certificate is strongly discouraged and limited to temporary testing. When a valid certificate is installed, validation should use the supported trusted-certificate, thumbprint or public-key strategy.

C4 stores configuration, logs and user settings in a central Microsoft SQL Server database for each installation. Application access uses stored procedures that are parameterized, with parameter validation and authorization before the call. Dynamic SQL queries are not used, and stored-procedure definitions are encrypted.

Clients and plugins access C4 data through the application server rather than through direct connections to the C4 database. This keeps application data access within the server-side permission model. Encryption of procedure definitions does not establish encryption of the information stored in the database.

Sensitive data includes user credentials, credentials used to access external systems, and personal data. For Level 2, sensitive data must be encrypted at the application level independently of database-level encryption; plaintext storage is not permitted. User authentication passwords are additionally subject to the OIDC requirements in Chapter 4.

Database encryption is administered outside C4 to match the customer's policies. The SQL Server connection string is described as encrypted. Neither fact demonstrates that application-level encryption covers every sensitive-data category. Sensitive-data encryption and classification also appear in the planned improvements, so the deployed implementation and coverage require confirmation.

Level 1 permits database-level and environmental protection only under its trusted-environment assumptions and with explicit risk acceptance. The separate criteria requiring Level 2 still apply.

Private keys must use operating-system certificate stores on Windows or protected storage on Linux. Only authorized processes may access keys; plugins must not receive key material. Key rotation follows organizational policy. The deployment must establish which keys are used and how these requirements are implemented.

The described controls include stored-procedure parameter validation and explicit object-type validation for serialization using System.Text.Json. Broader centralized validation of plugin and external-system input is also identified as a future enhancement. Existing validation checks must therefore not be represented as proof that the entire planned validation model is already implemented.

Plugins run in a C4 host that provides Simple Client access. Developers declare the data scope needed by the plugin, and sandbox restrictions limit its requests, for example by permitting personal-data access without granting credential access. Plugins do not receive direct access to the C4 SQL Server database.

Drivers and IS Connectors use Plugin Runner processes managed by Plugin Manager. Separate processes help isolate dependencies required by different external-system SDKs. This process arrangement and the request restrictions must not be treated as a guarantee that a compromised plugin cannot affect any other component; internal-threat protection is also part of the roadmap.

C4 and its plugins have separate development, deployment and maintenance lifecycles. A third-party developer operates under a developer agreement, and responsibility for the extension is defined separately from the core platform.

Both evaluations are mandatory before an integration plugin is digitally signed by Gamanet, published in the Plugin Store and released for customer installation. Level 2 explicitly requires Verified and Certified plugins. The result concerns the evaluated plugin and integration; it does not constitute independent certification of the entire customer installation.

The Plugin Store is the designated distribution source. Plugins require the applicable license and Gamanet digital signature; unsigned or modified plugins are rejected. Third-party installation also requires approval by the installation manager on the end-user side.

A signature, approval and technical evaluation serve different purposes. Signing identifies the accepted software package, installation approval authorizes its use at the site, and Verification and Certification assess its behavior at the two interfaces. Each remains relevant when reviewing a new plugin or update.

Setup checks the operating environment against the installed version's requirements. The described defaults disable unused services and ports, enable secure communication and install no plugins. Administrators add the plugins needed for the project. Plugin tracing starts at Warning level; more detailed tracing is an administrator-controlled setting.

Initial account provisioning requires release-specific confirmation before handover. Confirm whether an initial Support account is created and how its credentials are assigned. Where a default password is used, a first-login password change must be enforced. Do not assume the absence of default credentials without checking the deployed release.

For Enterprise Security, test and production environments must be separated. Application updates, patches and new plugin versions must be tested before being moved to production. Setup asks the administrator to perform a database backup before an upgrade.

The described development process uses Develop, Stable, Prerelease and Release stages, dedicated build servers, and beta testing before production release. Gamanet libraries are digitally signed, and a dedicated signing server holds the code-signing private keys. Builds also produce an inventory of external libraries used in the core application. These are software-delivery controls, not a substitute for customer-environment validation.

Client activity is recorded as application logs in the central C4 database and is available to users with the required permission. Communication between plugins and external systems is logged to files through NLog; server administrators access those files and configure their retention. The configured trace level affects the diagnostic information available.

The security requirements exclude passwords, keys, tokens and sensitive personal data from logs. Diagnostic output and plugin behavior must be assessed against that requirement. Logging confidentiality and integrity are also identified for improvement in the roadmap, so the exclusion requirement is not by itself evidence that every log is protected.

In the centralized multi-site model, one logical C4 Server and database serve multiple sites. Multiplying integration and workflow services expands processing capacity while retaining that shared installation. It does not, by itself, provide failover protection or make each site operationally independent.

Where sites must operate independently, C4 Enterprise Edition provides central monitoring and control above separate site installations. In the critical-infrastructure scenario, each site uses clustered C4, its own database and local monitoring. The central operations room gains information and control without replacing local operations.

Clustering can protect the shared C4 Server or the local installations in an Enterprise architecture. The design must also consider database, storage, network and external-system dependencies. Recovery behavior and acceptance tests are project-specific; a cluster diagram does not promise uninterrupted service or a fixed recovery time.

These responsibilities describe the security work that must be coordinated. Contractual ownership and service obligations are agreed for the project rather than inferred from this overview.

Internal TCP/IP is encrypted but not yet authenticated, and Named Pipes is described as unauthenticated. Exported logs are compressed but not encrypted or integrity-protected. These are specific implementation limitations, not simply configuration preferences.

Application-level sensitive-data encryption and comprehensive plugin-input validation are required in the target model and also appear among planned improvements. The information does not establish complete implementation coverage for an installed release. Confirmation must address the actual data categories, interfaces and controls used by the project.

C4 2027 identifies the planned release for these improvements; it is not evidence that a particular build has delivered them. Release information and validation must establish the implemented scope and any remaining limitations.

Confirm which security level is required and why, which sites and systems are included, and whether local operational independence is needed. Identify the exact C4 release, plugin versions, identity provider and infrastructure to be evaluated. Agree who supplies the evidence and who is authorized to accept residual risk.

The review should establish that user identity, record-level permissions, certificate validation, internal channels, plugin approval, sensitive-data protection and log handling meet the project requirements. It should also confirm how changes are tested and how the complete service is recovered. Chapter 10 identifies the limitations that must not be hidden by a general enterprise-security claim.

[1] What is C4 - Platform Overview, version 9.0. This companion explains the product, general deployment scenarios, Simple Client capabilities, developer ecosystem and licensing. Its centralized and independent-site deployment descriptions provide the operating context for Chapter 9.