Automating PKI and HSM Monitoring with AI-Powered Insights

A Certificate Revocation List (CRL) is a signed list of certificates that were revoked before their expiry date. Unlike many infrastructure failures, CRL expiry does not necessarily trigger an alarm. The CRL simply expires once its validity period ends. RFC 5280 (section 5.1.2.5) defines nextUpdate as the date by which the next CRL will be issued, so the Certificate Authority (CA) must sign and publish a replacement before then. If a lost Hardware Security Module (HSM) connection stops the signing, or an unreachable CRL Distribution Point (CDP) stops the publishing, the CA service keeps running and the infrastructure dashboards stay green. The first indication of a problem may be a relying party rejecting a certificate. 

This is why Public Key Infrastructure (PKI) and HSM monitoring must work together. The PKI layer covers the CA service, CRL and Online Certificate Status Protocol (OCSP) endpoints, certificate issuance, and templates. The HSM layer covers the module, connectivity, high availability (HA), and hardware health. A fault in one layer can surface as a symptom in the other, making the root cause difficult to identify. Manual checks often assess each layer independently using separate tools, at different times, with limited visibility into historical issues and recurring failures. 

Automated monitoring bridges this gap by performing scheduled checks across both layers, validating failures, generating timely alerts, retaining evidence, and providing consistent visibility. This blog walks through how PKI and HSM health is checked manually today, where that approach falls short, and why automation deserves consideration. It then covers what automation adds, how to measure the difference, and how the PKI and HSM monitoring extensions from Encryption Consulting (EC) use automated monitoring with artificial intelligence (AI)-powered insights to reduce routine manual work while corrective actions (such as restoring HSM connectivity or republishing a CRL) stay with authorized PKI and HSM engineers. 

Key Takeaways 

• PKI and HSM monitoring must go beyond server uptime to assess CA availability, certificate operations, cryptographic dependencies, HSM health, and HA status. 
• Manual checks and disconnected monitoring tools can delay failure detection, leave operational gaps between checks, and increase the effort required to investigate incidents. 
• Automated monitoring provides scheduled health assessments, consistent telemetry collection, configurable alerts, historical reporting, and faster access to incident evidence. 
• Effective automation distinguishes between an outright outage and a degraded condition, such as a failed HSM member or an unhealthy supporting service, so teams can respond according to operational risk. 
• EC’s PKI and HSM monitoring extensions support monitoring across Microsoft Active Directory Certificate Services (ADCS), Entrust nShield, and Thales Luna Network HSM and Data Protection on Demand (DPoD) environments, though specific capabilities vary by component and platform. 

Understanding PKI and HSM Monitoring 

PKI establishes the trust framework used to authenticate identities, secure communications, and validate digital signatures. A CA issues and signs digital certificates, while certificate lifecycle processes manage issuance, renewal, revocation, and expiration. Depending on the architecture, the environment may also include OCSP responders, CRLs, registration services, directory services, and applications that depend on certificate-based authentication. 

An HSM protects cryptographic keys and performs cryptographic operations within a dedicated security boundary. When a CA uses an HSM-backed private key, each signing request is passed to the HSM, which performs the operation without exposing the key. The CA’s signing function therefore depends on the HSM, its client software, connectivity, authentication, and cryptographic configuration, not only on the CA service. 

These dependencies create two complementary monitoring requirements. 

• PKI monitoring: Monitors the operational health of CAs and certificate-related services, including CA service availability, certificate issuance and processing, certificate expiration, and revocation mechanisms such as CRL and OCSP. 
• HSM monitoring: Monitors HSM availability and connectivity, partition or slot accessibility, hardware health, cryptographic operation status, performance metrics, and HA health and failover readiness, where supported. 

Neither monitoring domain completely replaces the other. A healthy CA does not necessarily indicate that its HSM is available, while a healthy HSM does not establish that the CA can successfully process certificate requests. Effective monitoring must evaluate the relevant components and dependencies together. 

How PKI and HSM Monitoring Works Today 

In many environments, monitoring combines native vendor utilities, operating system tools, application logs, infrastructure monitoring platforms, and periodic checks performed manually by PKI or security engineers. While infrastructure monitoring provides visibility into server availability and resource utilization, assessing the health of certificate authorities and their cryptographic dependencies often requires additional, platform-specific checks. 

A typical monitoring routine may include the following activities: 

• Checking CA availability: Confirming that the CA service is running, the host is reachable, and relevant system resources remain within expected operating limits. 
• Reviewing certificate operations: Inspecting certificate lifecycle operations including issuance activity, pending requests, renewal workflows, expiration reports, and relevant CA database records or event logs. 
• Verifying revocation services: Checking CRL publication status, publication locations, validity periods, and OCSP responder health, where applicable. 
• Inspecting HSM status: Using vendor utilities to examine device availability, client or hardserver services, partition or slot accessibility, Security World status, and HA group membership, depending on the platform. 
• Reviewing hardware and performance indicators: Examining available CPU, memory, temperature, storage, and cryptographic workload metrics, where supported by the HSM platform and its monitoring interfaces. 
• Reviewing logs: Examining CA events, operating system logs, HSM client logs, and appliance logs to identify errors, warnings, authentication failures, or connectivity problems. 
• Recording findings and escalating incidents: Documenting abnormal conditions, notifying the responsible team, creating incident tickets, and tracking recovery through operational tools. 

These activities provide valuable operational insight. Vendor utilities expose platform-specific information, while logs and diagnostic commands help engineers investigate failures and identify their underlying causes. However, the effectiveness of this approach depends on the frequency and coverage of the checks, the availability of monitoring data, and the procedures used to review and escalate findings. 

The limitations of periodic checks become more apparent when failures occur between inspections. For example, an issuing CA’s HSM connectivity may be verified during the morning shift, but the connection can fail shortly afterward. The earlier check provides no indication of the failure. Without frequent automated checks, the issue may go undetected until the next scheduled inspection or until a dependent operation, such as certificate signing, fails. 

This challenge becomes more difficult to manage as PKI environments grow in scale and complexity. Across multiple CAs, HSMs, servers, and deployment locations, maintaining consistent monitoring coverage requires increasing operational effort, and the more checks that depend on manual execution, the greater the chance of missed steps and human error. The challenge is not the absence of diagnostic tools, but the need to collect and evaluate health information consistently, identify failures between scheduled inspections, and make findings available to the teams responsible for investigating and resolving PKI and HSM issues. A consistent PKI and HSM monitoring process brings these checks together, helping teams identify dependencies that isolated health checks may overlook. 

Why Manual PKI and HSM Monitoring Falls Short 

Manual monitoring provides useful point-in-time information, but it can struggle to deliver continuous, consistent visibility across a distributed cryptographic environment. Some of the limitations of manual PKI and HSM monitoring are: 

• Snapshot output: A diagnostic command reports the state of a component when it runs. A failure that occurs and recovers between periodic checks may go undetected, although corresponding events may still be recorded in system logs. 
• Certificate lifecycle blind spots: Manually reviewing certificate expiration dates, renewal schedules, and CA issuance activity across multiple environments can be time-consuming. Without regular, consistent checks, approaching expiration dates, stalled issuance workflows, or unexpected changes in certificate activity may go unnoticed until they affect dependent services. 
• Configuration and policy drift: Changes to CA configuration, certificate templates, HSM partitions, access permissions, or HA settings can affect service reliability and security. When configuration checks are performed manually, inconsistencies between systems or deviations from established baselines may be difficult to identify promptly. 
• Signing-path failures: Loss of HSM connectivity can prevent a CA from completing HSM-backed signing operations even while the CA service remains running. Similarly, OCSP responses may stop being refreshed if the responder depends on an unavailable HSM-backed signing key. The impact depends on the architecture and available redundancy. 
• Hidden redundancy loss: In an HSM HA deployment, the failure of one member may not interrupt service if the remaining members can continue processing cryptographic operations. Thales Luna documentation confirms that when a member of an HA group fails, the group’s HA status shows a device error for that member, while pending operations are rescheduled across the remaining members. A monitoring process that checks only overall availability may therefore miss the loss of redundancy. 
• Scattered evidence: When monitoring information is distributed across separate systems, correlating a CA event, an HSM log entry, and a failed health check can require engineers to inspect multiple sources and align timestamps manually. This increases the effort required to establish the sequence of events and identify the underlying cause. 
• Inconsistent monitoring coverage: Different CAs, HSM models, operating systems, and deployment locations may require different diagnostic utilities and procedures. Maintaining consistent check frequency, validation criteria, and escalation processes across these environments becomes increasingly difficult as the infrastructure grows. 
• Limited alerting and escalation: Manual checks depend on someone reviewing the results and recognizing when intervention is required. Without automated thresholds, notifications, and escalation procedures, critical failures or degraded states may remain unnoticed until an engineer performs the next inspection or a dependent service reports an issue. 
• Limited historical and trend analysis: Individual diagnostic outputs provide snapshots but may not be retained in a consistent, searchable format. Without historical records of availability, errors, performance, and recurring failures, teams have less evidence for identifying trends, investigating repeated incidents, and assessing whether reliability is improving or deteriorating. 

The operational consequences become clearer when a failure affects a time-sensitive PKI process. Consider a typical scenario. An enterprise issuing CA in a private PKI is configured to publish a CRL every seven days, with an overlap period before the previous CRL expires. If the CA loses access to its HSM shortly after a publication, HSM-backed signing operations fail, so the next CRL cannot be signed or published. 

A failure detected within minutes leaves days to recover. A failure detected late in the publication cycle leaves hours. Once the published CRL passes its nextUpdate time without a replacement, relying parties that require current revocation information may encounter revocation-checking failures. The actual timing and impact depend on the configured CRL validity, overlap period, publication schedule, revocation-checking policies, and caching behavior. Where delta CRLs are used, their shorter validity narrows the window further. 

This scenario illustrates why effective monitoring requires more than occasional checks. It requires a repeatable mechanism for collecting operational information, evaluating health, identifying failures and degraded states, and making relevant evidence available for timely investigation. Automated monitoring can help reduce detection gaps and improve incident response, giving PKI teams more time to address problems before they affect dependent services. 

Why PKI and HSM Monitoring Should Be Automated 

Automation helps to make monitoring consistent, repeatable, and less dependent on manual intervention. It does not eliminate the need for experienced PKI and HSM engineers. Instead, it reduces the routine effort required to identify abnormal conditions and provides engineers with better information for investigation and response. Automated PKI and HSM monitoring makes routine health checks more consistent and helps reduce gaps between manual inspections.

Automated monitoring can execute approved health checks at defined intervals, record results, evaluate conditions against configured thresholds or health criteria, and notify the responsible team when an issue is confirmed. For PKI, this improves visibility into CA health and certificate-related operations. For HSMs, it helps assess device availability, supporting services, partition accessibility, HA status, and available hardware or performance indicators. 

The operational value of automation becomes clearer when viewed through the following considerations. 

• Faster detection: Scheduled checks run independently of staffing schedules, reducing the gap between issue occurrence and detection. 
• Consistent execution: Standardized monitoring procedures reduce dependency on manual routines and help ensure that defined checks are performed consistently. 
• Reduced operational risk: Timely detection of component failures and degraded conditions gives teams more opportunity to investigate and respond before an issue affects dependent PKI operations. 
• Scalability: As the number of CAs, certificate templates, HSMs, and vendors increases, automated checks help maintain consistent monitoring coverage without a proportional increase in repetitive manual work. 

These points show how automation makes monitoring faster, more consistent, and easier to scale across multiple CAs and HSMs, so failures are more likely to be caught before relying parties notice them. 

How Automation Improves PKI and HSM Monitoring 

Automation delivers value not simply by executing checks on a schedule, but by turning their results into actionable operational information. It connects health assessment with alerting, reporting, and investigation, helping teams move from periodic inspection to a more consistent monitoring process. 

• Scheduled collection: Health checks run at defined intervals, with results recorded to maintain a consistent record of component status without relying on manual inspections. 
• Failure confirmation: Consecutive health checks can help distinguish persistent failures from transient interruptions before an incident is confirmed, which reduces false alarms from a single missed response. 
• Automated alerting: Once a condition is confirmed, the responsible teams are notified automatically through channels such as email, so issues reach the right people without waiting for the next manual check. 
• Scheduled health reports: Detailed health reports can be generated automatically, providing stakeholders with structured information on component health at the time of generation. 
• Retained logs and incident history: Retention policies preserve relevant logs and incident records for later investigation, helping engineers establish event sequences, review recurring failures, and assess recovery. 
• Resilience visibility: Scheduled checks can identify changes in HA membership and status where the platform exposes them, making redundancy visible even when the remaining HSM members continue processing cryptographic requests. 
• Reduced repetitive workload: Engineers spend less time performing routine checks and compiling information manually, allowing more time for diagnosis, remediation, risk assessment, and infrastructure improvement. 
• Faster incident investigation: Consolidated health results and relevant logs provide an initial evidence base for troubleshooting, reducing the need to gather information separately from every monitoring source. 

These capabilities are most effective when implemented as part of a broader monitoring architecture. Infrastructure monitoring, PKI monitoring, HSM monitoring, and certificate lifecycle management address different operational requirements. Combining their findings helps teams understand not only whether individual components are healthy, but also whether the dependencies supporting critical PKI operations remain available and resilient. 

How AI-Powered Insights Enhance PKI and HSM Monitoring 

In PKI and HSM monitoring, AI-powered insights can help engineers correlate available records, review incident history, and investigate failures across connected components. AI serves as an investigation and explanation layer on top of the monitoring data. It uses collected metadata and recorded operational data to help operators investigate issues, understand system behavior, and retrieve relevant findings through a conversational interface. 

• Natural-language queries: Operators can ask an AI assistant about CA status, certificate requests, CRL status, HSM health, and incident history in plain language. The assistant retrieves relevant information from the collected monitoring metadata, reducing the need to navigate multiple dashboards and data sources. 
• Evidence-based responses: Answers are grounded in available monitoring records, metadata, and logs. The AI explains recorded findings rather than independently determining the state of a CA or HSM, which keeps its responses tied to evidence. 
• Cross-layer correlation: Timestamped records help operators investigate relationships between events across PKI and HSM components, such as whether an HSM connectivity failure coincided with certificate issuance or signing errors. 
• Incident sequence reconstruction: By bringing together health-check results, log events, and incident records, AI helps organize available evidence chronologically, making it easier to understand how an issue developed and which events occurred before or after the failure. 
• Historical incident review: Operators can examine previous incidents and recorded errors to identify recurring failure patterns, compare similar events, and support root-cause investigations. 
• Faster troubleshooting: By retrieving relevant records, summarizing findings, and connecting related events, AI reduces the manual effort required to investigate issues across separate monitoring sources. Engineers can use these findings to guide further diagnosis and determine appropriate corrective actions. 

While AI-powered insights help teams interpret monitoring data and investigate incidents more efficiently, the overall effectiveness also depends on how health checks, alerts, reporting, and evidence collection are performed. The following section compares manual and automated approaches to highlight these operational differences. 

Manual Versus Automated PKI and HSM Monitoring 

The following comparison summarizes the operational differences between predominantly manual monitoring and a well-configured automated monitoring approach. 

Monitoring dimension	Manual monitoring	Automated monitoring
Health-check frequency	Depends on inspection schedules and operator availability	Executes configured checks at defined intervals
Failure detection	Failures may remain undetected until the next inspection or a dependent operation reveals the issue	Detects failures that fall within the scope of configured checks, subject to check frequency
CA visibility	Requires engineers to review CA services, diagnostic outputs, and relevant logs	Collects and evaluates configured CA health indicators and monitoring results
HSM visibility	Requires manual inspection using supported vendor utilities, service checks, and logs	Automates supported HSM availability, connectivity, partition or slot accessibility, and HA status checks
HA degradation	Reduced redundancy may go unnoticed while cryptographic operations continue through the remaining HSM members	Identifies configured HA degradation conditions when member-level status is exposed and monitored
CA template configuration drift	Typically identified during manual reviews, troubleshooting, or audits	Compares current template configuration with industry best practices and alerts on deviations from it
Alerting	Depends on someone reviewing findings and escalating issues	Sends notifications when configured alert conditions are met
Incident creation	Often requires manual ticket creation and evidence collection	Can create incident tickets through configured integrations, such as Jira
Troubleshooting	Requires engineers to gather and correlate evidence across separate sources	Provides consolidated health information and retained logs for investigation
Historical analysis	Depends on the completeness of manually maintained records	Supports trend analysis and incident reconstruction when history is retained
Reporting	Requires manual compilation or separate reporting tools	Generates downloadable health reports on demand or at configured intervals
Operational workload	Routine checks and evidence collection consume engineering time	Reduces repetitive manual checking and reporting effort, freeing engineers to focus on investigation and remediation
Response and recovery	Depends on detection, escalation, and established response procedures	Improves detection and notification, but recovery still depends on response procedures and authorized corrective actions

Automation does not guarantee that every failure will be detected or resolved before service is affected. Its practical advantage is that it makes defined checks more consistent, reduces dependency on manual inspection, and improves the speed and quality of the information available to responders. 

Measuring the Difference 

A practical way to evaluate manual versus automated PKI and HSM monitoring is through controlled lab tests that simulate failures across both layers and their dependencies. Test scenarios should cover CA service availability, certificate issuance and signing, CRL publication, OCSP availability, HSM connectivity, and HA degradation, where applicable. For each scenario, compare the results from manual inspections with those from the configured monitoring solution. 

The following measurements should be recorded: 

• Detection: Failure injection time, first manual detection time, automated detection time, and time taken to confirm a failure. 
• Alerting and incident tracking: Alert generation and delivery times, along with Jira ticket creation time, where integration is enabled. 
• PKI service impact: Whether the failure affects CA availability, certificate issuance or signing, CRL publication, or OCSP responses, and how quickly the affected function is identified. 
• HSM health and resilience: Time taken to detect HSM connectivity failures, partition or slot inaccessibility, hardware errors, and HA degradation, where supported. 
• Investigation efficiency: Time required to correlate PKI and HSM events, establish the sequence of events, and identify the likely cause. 
• Recovery verification: Time taken to detect restored connectivity or service availability and confirm that affected PKI operations are functioning correctly. 

Run each scenario under comparable conditions and repeat the tests to account for variability. Record any monitoring gaps, missed alerts, and false positives alongside detection times. 

These measurements provide a practical basis for evaluating monitoring coverage, detection performance, investigation effort, and recovery visibility across the complete PKI environment, not just the CA or HSM in isolation. 

How Encryption Consulting Can Help 

EC’s PKI Prime monitoring extensions are designed to improve operational visibility across the systems that issue certificates and protect cryptographic keys. The PKI extension monitors Microsoft ADCS, and the HSM extension monitors Entrust nShield and Thales Luna, so each layer of the environment is covered. 

Key capabilities include: 

• CA service and revocation health: Checks the ADCS CA service (CertSvc) and Online Responder service status at configurable intervals as short as a few seconds. A background monitor validates the certificate chain, checks CDP, Authority Information Access (AIA), and OCSP reachability, reports any failures, and sends warning alerts before CRLs or certificates expire, so teams can act before an outage. 
• Issuance and enrollment failures: The extension queries the CA database at a configured frequency to identify failed or denied certificate requests and capture the denial reason text. It also cross-references denied enrollments against live template permissions to flag a requester with no enrollment right on any template. 
• HSM availability, resilience, and health: Monitors nShield module and hardserver status and Luna slot and partition status at configurable intervals, along with nShield Security World status and quorum configuration, and Luna HA group membership and health, helping identify degraded redundancy where supported. Also tracks the performance and capacity indicators each platform exposes, such as CPU, memory, temperature, and cryptographic throughput on nShield and storage utilization on Luna. 
• Configuration drift detection and template compliance: The extension maintains an append-only history of published certificate template configurations for baseline comparison, alerts on changes that degrade a template’s configuration, and warns about templates that do not align with industry best practices. On the HSM side, the extension checks nShield firmware compliance and compares Luna partition policies against a defined baseline configuration, alerts on deviations that weaken the configuration, and warns about settings that do not align with industry best practices. 
• Log collection and error monitoring: Collects and retains nShield hardserver logs, Windows Event Log entries, Luna client logs, and Luna Network HSM appliance logs, along with monitoring results and incident records, according to configurable retention policies. Logs can be viewed in sortable and filterable views. The extension also scans the Windows Event Log for Error-severity entries, and alerts are raised for error-level events where the log source reports severity. 
• Alerting and incident management: On the CA side, a single scanner evaluates four conditions: CA service down, CRL overdue, a Critical event log entry, and a critical template baseline finding. On the HSM side, the extension alerts on defined critical conditions across module and partition availability, HA health, and configuration drift. Failure alerts are raised after consecutive failed checks, which reduces false alarms from a single missed response. They are sent to Microsoft Teams through a configured Teams Workflows webhook and by email, and qualifying incidents automatically create Jira tickets, helping teams track issues, investigate failures, and coordinate remediation. 
• Scheduled and on-demand reporting: Generates detailed health reports at configurable intervals or on demand. Reports can be downloaded in PDF format for offline review, documentation, and sharing with stakeholders. 
• AI-powered conversational insights: Allows operators to ask questions through Claude Desktop about CA status, certificate requests, CRL health, HSM availability, and incident history. Claude uses metadata collected by the monitoring extensions to provide answers, helping teams investigate issues without manually searching multiple data sources. 
• Read-only operation: Both extensions are designed to be read-only, so monitoring is not intended to change CA or HSM configuration. 

Together, these capabilities provide visibility across PKI services and HSM infrastructure, from certificate issuance and revocation to cryptographic hardware health and high availability. With scheduled monitoring, configurable Teams and email alerts, Jira integration, downloadable health reports, and retained evidence, EC helps teams reduce repetitive manual checks, detect issues earlier, and investigate incidents more efficiently. AI-powered insights further simplify access to monitoring data, while corrective actions remain under the control of authorized engineers. 

To see these capabilities live, schedule a demo with our team. For questions, write to [email protected]. 

Conclusion 

A well-designed PKI and HSM monitoring strategy combines scheduled checks, actionable alerts, historical evidence, and timely investigation to strengthen operational readiness. PKI and HSM environments support critical security functions, from certificate issuance and revocation to private-key protection and cryptographic signing. Their operational health depends on multiple interconnected components, and a failure in one dependency can affect the wider environment even when the CA server or HSM appears operational in isolation. Manual checks, vendor utilities, and infrastructure dashboards remain valuable, but they cannot always provide the frequency, consistency, and correlation required to identify failures and degraded conditions promptly. 

Automated monitoring can improve this process by collecting health information at configured intervals, identifying defined abnormal conditions, generating timely alerts, retaining operational evidence, and supporting incident investigation. When implemented with appropriate access controls and platform-specific checks, it can reduce repetitive operational effort and give PKI and security teams better visibility into the state of their cryptographic infrastructure. It also helps distinguish current service availability from the resilience required to maintain that availability when another component fails. 

EC’s PKI and HSM monitoring extensions bring these capabilities to supported CA and HSM environments through scheduled health checks, centralized reporting, Teams notifications, email alerts, Jira incident integration, log review, and AI-powered insights using Claude. By improving visibility across both the CA and the cryptographic systems on which it depends, organizations can strengthen operational readiness and respond to problems with greater consistency. 

The objective is not to eliminate every failure, but to reduce the time required to detect, understand, and address issues before they escalate into broader PKI disruptions. 

Frequently Asked Questions 

What is the difference between PKI monitoring and HSM monitoring? 

PKI monitoring focuses on the operational health of CAs and certificate-related services, including configured certificate lifecycle and revocation indicators. HSM monitoring focuses on the cryptographic infrastructure protecting private keys and performing cryptographic operations, including availability, supporting services, hardware indicators, and HA status where supported. Both are necessary for understanding the health of an HSM-backed PKI environment.

Why monitor the HSM separately from the CA? 

When the HSM is unreachable, signing operations fail even though the CA service may appear healthy. HSM availability, connectivity, HA status, and logs therefore need their own checks. 

Can automated monitoring prevent PKI or HSM outages? 

Monitoring cannot prevent every hardware failure, software defect, connectivity interruption, or configuration problem. It can reduce the time between the occurrence of a detectable condition and its identification. Early detection of HSM connectivity failures, degraded HA configurations, abnormal performance indicators, or CA service problems gives engineers more time to investigate and recover before the impact expands. 

Which CA and HSM platforms do EC’s PKI and HSM monitoring extensions support

EC’s PKI monitoring scope includes Microsoft ADCS and its HSM scope includes Entrust nShield and Thales Luna environments, including Luna Network HSM and Thales DPoD. The specific metrics and checks available depend on the platform, deployment architecture, vendor interfaces, and configured monitoring capabilities. 

What do AI-powered insights do? 

They let operators ask about PKI and HSM state, incidents, and reports in plain language. The AI does not independently determine state. It interprets data that monitoring has collected. 

Can the extensions fix a failed CA or HSM? 

No. They detect, alert, record, and explain. Both extensions are designed to be read-only, and corrective actions stay with authorized engineers.