Standing privilege is the risk
Long-lived shared credentials and bastion accounts give providers permanent reach. When someone leaves, the key often stays. Clients cannot prove least privilege if access is ambient.
Operator Trust
If a provider connects to your servers or retrieves your secrets, you need a full trail: roles, scopes, sessions, and timestamps. CertLocker gives clients RBAC over secrets and tokenised, just-in-time access to hosts, so operator trust is measurable, not assumed.
Managed service providers, integrators, and support teams routinely need access into customer environments. Without a governed control plane, that access lives in shared keys and chat threads. The client has no independent record of who touched their estate.
Long-lived shared credentials and bastion accounts give providers permanent reach. When someone leaves, the key often stays. Clients cannot prove least privilege if access is ambient.
Procurement and security teams ask: who had access, to which hosts and secrets, and did they connect? If the provider cannot answer from systems instead of spreadsheets, the relationship stalls.
The client must be able to review access independently of the operator's word. A control plane the client can see turns careful process into exportable, time-stamped events.
Two capabilities close the gap between “we need access to help you” and “you can prove what we did.”
RBAC
Secrets, PEMs, keys, and operational credentials sit under role-based access, not a shared vault password. Operators retrieve only what their role and group allow; every retrieval is an auditable event.
Client sees: who was granted which secret scopes, when material was retrieved, version history, and revoke/rotate without redistributing files.
Tokens
SSH, RDP, and VNC sessions are issued as scoped, time-bound tokens, not standing admin keys. Access inherits identity, protocol and IP constraints, and optional 2FA at issuance.
Client sees: who was allowed which hosts, whether a session was opened, when it started and ended, and revoke without rotating a shared key across the fleet.
Operator trust answers four questions for every secret and host: who, what, whether, and when.
| Question | Without a control plane | With CertLocker |
|---|---|---|
| Who can access this host? | Shared key / bastion account list | RBAC + token scope per identity and group |
| Who can retrieve this secret? | Vault login or password manager share | Role-scoped retrieval with event history |
| Did they connect? | Hope the provider kept notes | Session events: issued, opened, closed |
| When? | Email threads and ticket comments | Immutable timestamps on every access event |
| Can we cut them off now? | Rotate keys everywhere, hope nothing was copied | Revoke token / role; standing privilege ends |
Who
Identity on every grant and session
What
Secret scope or host target
Whether
Retrieval or connection occurred
When
Issue, open, and close timestamps
ISO/IEC 27001:2022 expects controlled access, privileged access management, and logging. Operator access into client systems is exactly where Annex A controls are tested in practice. Use this as supporting operational evidence, not a claim that CertLocker replaces your ISMS.
| Annex A control | Operator-trust angle | CertLocker evidence |
|---|---|---|
| A.5.15 Access control | Need-to-know reach into client secrets and hosts | One RBAC model across secrets, tokens, and host sessions |
| A.5.18 Access rights | Grant, review, and revoke provider access | Scoped tokens, groups, revoke / rotate without shared keys |
| A.8.2 Privileged access | Admin-level operator sessions must not be standing | Time-limited / 2FA SSH, RDP, VNC instead of long-lived keys |
| A.5.17 Authentication information | Credentials must not be scattered or shared casually | Central custody of secrets and PEMs with scoped retrieval |
| A.8.15 Logging | Prove who accessed what and when | Audit events for secret retrieval and host-access sessions |
| A.8.16 Monitoring | Detect and review anomalous operator activity | Session and retrieval history available for review |
| A.5.19 / A.5.21 Suppliers | Clients must manage supplier access to their information | Client-visible grants and trails for provider operators |
Dig deeper on ISO 27001 evidence with CertLocker.
SOC 2 Security (and often Confidentiality) ask whether logical access and monitoring actually work for people who can reach customer systems, including third-party operators. CertLocker produces operational evidence; it is not a SOC 2 report.
CC6
Restrict access to systems and data based on roles. Tokenised host access and RBAC on secrets operationalize least privilege for provider staff working in the client estate.
CC7
Detect and respond using monitoring and logging. Session and secret-retrieval events give clients and auditors a trail of operator activity rather than relying on tickets alone.
C1
Protect confidential information from unauthorized access. Scoped secret retrieval and short-lived host tokens reduce exposure of keys and credentials shared with operators.
| Criterion | Auditor question | How CertLocker helps |
|---|---|---|
| CC6.1–CC6.3 | Are access rights authorized, reviewed, and removed? | Role grants, scoped tokens, revoke without redistributing keys |
| CC6.6 / CC6.7 | Are credentials and encryption keys protected? | RBAC custody of secrets/PEMs; no standing shared admin keys |
| CC7.2 / CC7.3 | Is activity monitored and anomalies investigated? | Who / what / whether / when events for secrets and hosts |
| CC9.2 | Are vendor / partner risks addressed? | Client-visible operator access model and audit trail |
| C1.1 | Is confidential data restricted to authorized parties? | Least-privilege secret scopes and JIT host sessions |
Dig deeper on SOC 2 evidence with CertLocker.
CertLocker makes operator access visible and revocable. It is not your full ISMS, SOC 2 programme, or CPA examination.
You still own policies, risk assessment, supplier contracts, and certification. Describe CertLocker as supporting evidence for selected ISO 27001 and SOC 2 controls, not as making the organisation certified.
In short: CertLocker helps clients prove who from a provider can reach secrets and servers, whether they connected, and when. Operator trust gets an audit trail behind it.
Operator trust is the ability for a client to know who from a service provider can reach their secrets and servers, whether they connected, and when. It turns “we are careful” into a client-visible audit trail of grants, retrievals, and sessions.
CertLocker puts provider access under RBAC for secrets and tokenised, time-limited access for SSH, RDP, and VNC. Every grant, retrieval, and session becomes an auditable event the client can review and revoke.
No. CertLocker supports evidence for selected ISO/IEC 27001:2022 Annex A controls and SOC 2 Trust Services Criteria around access, privileged access, logging, confidentiality, and supplier access. Certification and CPA examination still belong to your programme, not to the platform.