How MyCena addresses your compliance requirements

SOC 2 Type II — Trust Services Criteria

Security, Availability, and Confidentiality

SOC 2 evaluates controls relevant to security, availability, processing integrity, confidentiality, and privacy. The criteria most directly addressed by MyCena fall under the Common Criteria (CC) series — particularly access controls, logical security, and change management. The mappings below reference AICPA TSC 2017 criteria.

Control requirementHow MyCena addresses it

CC6.1Logical access security software, infrastructure, and architectures

MyCena generates and controls all credentials centrally. Users never possess credentials — eliminating the most common vector for unauthorised logical access. The organisation holds cryptographic control over every credential in scope.

Credential generation logs, access event audit trail, encryption key management records

CC6.2Prior to issuing system credentials, registration and authorisation of new users

Credential issuance in MyCena requires explicit administrator authorisation. No user can self-provision access. Every credential issuance event is logged with the authorising admin identity, timestamp, and system scope.

User provisioning log with approver identity, timestamp, and system scope per issuance event

CC6.3Role-based access and removal of access when no longer required

MyCena enables instant revocation of all credentials for any user across every connected system with a single command. Revocation is logged with timestamp, admin identity, and scope. Access cannot persist after revocation — the credential ceases to function immediately.

Revocation event log with timestamp and confirmation, demonstrating zero access window post-revocation

CC6.6Logical access security measures to protect against threats from outside the system boundaries

Because users never know or hold credentials, phishing and social engineering attacks cannot extract usable credentials. There is no credential for an external threat actor to steal from a user. Credential injection occurs at the point of authentication — never in user-accessible memory or storage.

Architecture documentation, browser credential blocking logs, zero successful phishing credential extractions

CC6.7Transmission and movement of information

Credentials are transmitted encrypted end-to-end. They are never present in plaintext in transit. The browser is actively blocked from saving or caching credential values. Audit logs capture all transmission events.

Encryption-in-transit logs, browser blocking confirmation, credential transmission audit records

CC7.2Monitoring for anomalies and security events

MyCena generates a real-time audit trail of every access event — who accessed which system, when, from which device and IP. Anomalous access patterns are surfaced in the dashboard and exportable for SIEM integration.

Real-time access event log, anomaly flagging records, SIEM-compatible export

CC9.2Vendor and third-party access management

All third-party and vendor credentials are generated, controlled, and revocable by the organisation — not the vendor. Vendor access is scoped per system, logged per event, and revocable instantly when the engagement ends. No manual offboarding required.

Third-party access log, vendor credential revocation records, scope limitation documentation

Audit evidence generated automatically by MyCena

Access event log

Every login event: user, system, timestamp, device, IP. Exportable. Tamper-evident.

Provisioning log

Every credential issuance: approver, user, system, timestamp. Complete chain of authorisation.

Revocation log

Every revocation event with timestamp and confirmation. Zero-window proof available.

Vendor access report

All third-party credentials in scope, last access, revocation status, per-system scope.

How to use this in an audit conversation

When your SOC 2 auditor asks about access control evidence, open the MyCena dashboard and export the access event log for the period under review. Every CC6 and CC7 access control criterion can be evidenced from a single export. The provisioning and revocation logs together demonstrate the full user lifecycle — from authorised issuance to confirmed termination — with no gaps.

HIPAA Security Rule — 45 CFR Part 164

Administrative, Physical, and Technical Safeguards

The HIPAA Security Rule requires covered entities and business associates to implement safeguards to protect electronic protected health information (ePHI). MyCena addresses several Technical and Administrative Safeguard requirements — particularly those related to access control, audit controls, and workforce controls. References are to 45 CFR Part 164 Subpart C.

Safeguard / standardHow MyCena addresses it

§164.312(a)(1)Access control — unique user identification

MyCena assigns and manages unique credentials per user per system. No shared accounts or shared credentials are possible — each credential is generated uniquely for one user and one system. Shared login is structurally eliminated.

Per-user credential issuance log, confirming unique credential per user-system pair

§164.312(a)(2)(i)Access control — automatic logoff

MyCena session controls can enforce credential expiry and re-authentication requirements. Credential validity windows are configurable per system. Expired credentials cannot be used without re-authorisation from the MyCena platform.

Credential validity configuration records, session expiry logs

§164.312(a)(2)(ii)Access control — emergency access procedure

MyCena administrators can provision emergency access credentials rapidly for break-glass scenarios. Emergency issuance is logged with reason, approver, and time-limited scope. Emergency credentials are revoked automatically at expiry or manually by any administrator.

Emergency credential issuance and revocation log with reason code and approver

§164.312(b)Audit controls — hardware, software, and procedural mechanisms

MyCena generates a comprehensive, tamper-evident audit trail of every access event to every connected system. Logs include user identity, system accessed, timestamp, device identifier, and IP address. Logs are exportable for integration with SIEM and audit management systems.

Complete access audit trail exportable in standard formats. Covering 100% of MyCena-mediated access events.

§164.312(c)(1)Integrity — protect ePHI from improper alteration or destruction

By controlling all credentials centrally, MyCena reduces the risk of unauthorised access that could lead to improper alteration or destruction of ePHI. No user who has been offboarded retains any credential that could enable continued access.

Revocation completeness logs demonstrating zero credential validity post-offboarding

§164.312(d)Person or entity authentication

MyCena ensures that only the specifically authorised user can access a system via their MyCena-managed credential. Credentials are device-bound and injection-only — they cannot be extracted and used from a different device or context.

Device binding logs, injection-only architecture documentation, access event records

§164.308(a)(3)Workforce security — authorisation and supervision

Every credential issuance requires administrator authorisation. Workforce members cannot self-provision access to any system. Termination triggers immediate credential revocation across all systems — no manual offboarding checklist required.

Workforce provisioning and revocation audit trail, demonstrating authorisation chain for every access grant

Audit evidence generated automatically by MyCena

Unique user access log

Confirms no shared credentials. Every access event tied to a single named user identity.

Workforce lifecycle log

Provisioning and revocation events for every workforce member. Termination-to-revocation time recorded.

Full access audit trail

100% of MyCena-mediated ePHI system access. HIPAA-compliant audit log format available.

Emergency access log

Break-glass events with reason, approver, scope, duration, and revocation confirmation.

How to use this in a HIPAA review

HIPAA auditors focus on three things in access control reviews: can you prove who accessed what and when, can you prove terminated employees lost access promptly, and can you prove no shared credentials exist. MyCena’s audit exports answer all three directly — without manual evidence collection. Export the access log, the workforce lifecycle log, and the revocation confirmation report for the audit period.

NIST Cybersecurity Framework 2.0

Govern, Identify, Protect, Detect, Respond, Recover

NIST CSF 2.0 (released February 2024) expanded the framework to six functions, adding Govern as the overarching function. MyCena addresses controls primarily within Govern, Protect, and Detect, with strong contributions to Identity Management and Access Control subcategories. References use the CSF 2.0 identifier format.

Function / categoryHow MyCena addresses it

GV.OC-01Govern — organisational context: roles and responsibilities

MyCena enforces a clear separation: the organisation controls all credentials, not individual users. This structural control assignment is itself a governance control — the organisation’s policy is enforced by architecture, not by training or procedure.

Administrator configuration records, role-based access policy documentation

PR.AA-01Protect — identities and credentials managed for authorised users

MyCena generates and manages all credentials centrally. Every identity has a unique credential. No credential is user-generated or user-held. Credential lifecycle — issuance, rotation, revocation — is under organisational control at all times.

Credential lifecycle log: issuance, rotation events, revocation confirmations per identity

PR.AA-02Protect — identities proofed and bound to credentials

Credentials are bound to specific user identities and specific devices at issuance. The credential cannot be extracted and used from a different identity or device context. Identity-to-credential binding is logged and verifiable.

Identity-credential binding records, device binding logs per issuance event

PR.AA-05Protect — access permissions managed, with least privilege

Credentials are scoped per system at issuance — a user is granted access to specific systems, not broad system classes. Lateral movement using a single compromised credential is structurally constrained.

Per-system access scope records, scope change audit log, per-user system access map

PR.AA-06Protect — physical access controlled

Credential injection is device-bound. A credential cannot be used from an unregistered device — even if a user is coerced or a device is stolen. Physical device loss does not automatically compromise access credentials.

Device registration log, access attempt records from unregistered devices (blocked events)

DE.AE-02Detect — anomalies and events analysed

MyCena’s real-time access event log enables detection of anomalous patterns — unusual access times, unusual source IPs, unusual system combinations, unusually high access frequency. Logs are SIEM-exportable for automated anomaly detection.

Real-time access event stream, anomaly detection export, SIEM integration records

RS.MA-01Respond — incidents managed

When an incident is detected, MyCena enables immediate credential revocation across all systems for the affected user — contained in seconds, not hours. Revocation is logged with timestamp, confirming the containment action and its exact time relative to incident detection.

Incident response revocation log: detection-to-revocation time, scope, confirmation

PR.PS-01Protect — software managed to reduce attack surface

By removing credentials from user possession entirely, MyCena eliminates the largest single attack surface in most environments — user-held credentials. This is a structural attack surface reduction, not a compensating control.

Architecture documentation. No credentials in user-accessible memory, browser storage, or password managers.

Audit evidence generated automatically by MyCena

Identity lifecycle log

Full credential lifecycle per identity: issuance, rotation, scope changes, revocation.

Access scope map

Per-user, per-system access scope at any point in time. Exportable for least-privilege review.

Anomaly detection export

Access events flagged for anomalous patterns. SIEM-compatible format.

Incident response log

Detection-to-revocation time per incident. Confirms containment speed and scope.

How to use this in a NIST CSF assessment

NIST CSF assessments score maturity against each subcategory. MyCena moves several PR.AA subcategories from “partial” or “risk informed” to “adaptive” maturity — because the controls are architectural, not procedural. When presenting to an assessor, lead with the structural argument: MyCena does not add a policy around credential management, it removes credentials from user possession entirely. That distinction moves the maturity needle more than any compensating control.

General Data Protection Regulation — EU 2016/679

Data Protection by Design, Security of Processing, Breach Notification

The GDPR requires organisations to implement appropriate technical and organisational measures to protect personal data. MyCena addresses several of the most frequently cited compliance gaps — particularly Articles 25, 32, and 33, which together cover data protection by design, security controls, and breach disclosure obligations.

Article / requirementHow MyCena addresses it

Article 25(1)Data protection by design — technical measures at design stage

MyCena implements credential control at the architectural level — before a user ever touches a system. By removing credentials from user possession entirely, the organisation structurally prevents the most common mechanism through which personal data is exposed.

Architecture documentation confirming credential injection model. No credentials stored in user-accessible form.

Article 25(2)Data protection by default — only necessary data processed

MyCena enforces least-privilege access by design. Credentials are scoped per user per system at issuance — no user receives broader access than their specific role requires. Access beyond what is necessary is structurally prevented.

Per-user access scope records. No user has credential access to systems beyond their defined scope.

Article 32(1)(a)Security of processing — pseudonymisation and encryption

All credentials managed by MyCena are distributed in encrypted form and injected without exposing plaintext to the user, the device clipboard, or browser storage. Credentials are never stored in plaintext at any point in the user lifecycle.

Architecture documentation confirming encryption in transit and injection-only distribution. Browser blocking confirmation.

Article 32(1)(b)Security of processing — ongoing confidentiality and integrity

Ongoing confidentiality is maintained by ensuring no user, contractor, or third party retains credential access after their authorisation ends. MyCena’s revocation mechanism ensures access is terminated across all systems simultaneously and confirmed in the audit log.

Revocation completeness log. Post-revocation blocked access confirmation. Zero open access windows after termination.

Article 32(1)(d)Security of processing — regular testing and evaluation of measures

The MyCena platform’s access event log enables continuous monitoring and regular review of who has accessed which systems. Regular access reviews can be conducted directly from the platform without manual data collection.

Access review export. Periodic access scope audit reports. Revocation test records.

Article 33Notification of breach to supervisory authority — 72-hour window

MyCena’s real-time audit log provides the evidence needed for a complete and accurate notification — which systems were accessed, by whom, when, and from where. Organisations with MyCena deployed can produce a complete access chronology immediately, without the manual log reconstruction that typically delays notifications.

Real-time access event log. Incident chronology export. Covers 100% of MyCena-mediated access to personal data systems.

Article 28Processor obligations — technical and organisational measures

Where the MyCena-deploying organisation acts as a processor, MyCena provides the technical controls that underpin the processor’s security obligations. The processor generates and controls every credential, and can demonstrate this with an audit log.

Processor security controls documentation. Third-party access log showing organisation-controlled credentials for all processor staff.

Recital 83 / Art. 32(2)Risk assessment — risks from accidental or unlawful destruction, alteration, unauthorised disclosure

Credential-based unauthorised access — phishing, insider misuse, stale access — is the highest-frequency risk in most environments. MyCena removes these risks structurally rather than mitigating them procedurally, materially reducing the residual risk a GDPR risk assessment must quantify.

Risk register update confirming structural elimination of phishing, credential sharing, and stale access vectors.

Audit evidence generated automatically by MyCena

Access event log

Every access to personal data systems: user, system, timestamp, device, IP. Supports 72-hour breach notification with complete incident chronology.

Access scope records

Per-user system access scope confirming least-privilege enforcement. Supports Article 25(2) data minimisation evidence.

Revocation completeness log

Post-termination revocation with timestamp. Confirms zero active access windows after employment or contractor engagement ends.

Processor control documentation

Technical control evidence for Article 28 processor security obligations. Supports due diligence questionnaires from data controllers.

How to use this in a GDPR review or DPA negotiation

Data Protection Officers and supervisory authorities focus on three questions in access control reviews: do you know who had access to personal data and when, can you demonstrate that access ended when it should have, and what would you be able to tell a regulator within 72 hours of a breach? MyCena answers all three from the same audit export.

Digital Operational Resilience Act — EU 2022/2554

ICT Risk Management, Access Controls, and Third-Party Governance

DORA became enforceable on 17 January 2025 for financial entities in the EU — banks, insurers, investment firms, payment institutions, and their critical ICT third-party service providers. MyCena directly addresses DORA’s ICT access management requirements under Articles 9 and 10, and the third-party risk governance requirements under Article 28.

Article / requirementHow MyCena addresses it

Article 9(2)ICT security — access rights management and authentication

DORA requires financial entities to implement strong authentication controls and manage ICT access rights on a need-to-know basis. MyCena removes credentials from user possession entirely — access rights are managed centrally by the organisation. Every credential is generated with a defined scope, logged at issuance, and revocable instantly.

Credential issuance log confirming per-user, per-system scoped access. No user-generated or user-held credentials.

Article 9(4)(c)ICT security — policies for privileged accounts and remote access

DORA specifically requires controls for privileged accounts and remote access channels. MyCena governs all account types under the same central control model — privileged accounts receive the same credential management discipline as standard accounts, with configurable scope restrictions, session controls, and audit logging.

Privileged account credential management log. Remote access session records. Scope configuration documentation.

Article 9(4)(d)ICT security — strong authentication for critical systems

DORA requires multi-factor or strong authentication for critical ICT systems. MyCena enforces credential quality at the source — credentials are cryptographically generated, unique per user per system, and device-bound. The injection model means the credential cannot be extracted and replayed.

Credential generation records confirming cryptographic quality. Device binding logs. Architecture documentation.

Article 10(1)ICT security testing — regular testing of access controls

DORA requires regular testing of ICT security controls. MyCena’s revocation test — built into the standard deployment process — provides a repeatable, logged demonstration that access controls function as specified. Each revocation test produces a timestamped record showing the exact time from revocation command to confirmed zero access.

Revocation test records: command timestamp, confirmation timestamp, systems covered, zero-access confirmation.

Article 28(2)Third-party ICT risk — contractual arrangements for access and security

DORA requires financial entities to manage the security of ICT third-party access. MyCena governs all third-party and vendor credentials under the same central control model as internal staff. Vendor credentials are scoped, logged, and revocable by the financial entity — not the vendor.

Third-party access log. Vendor credential revocation records. Scope limitation documentation per vendor engagement.

Article 28(4)(e)Third-party ICT risk — exit strategy and data access cessation

DORA requires entities to have exit strategies for ICT third-party arrangements, including confirmation that access to systems and data ceases at contract end. MyCena provides this confirmation structurally — vendor offboarding is a single revocation command that terminates all credentials simultaneously.

Vendor offboarding revocation log. Post-revocation blocked access confirmation. Supports DORA exit strategy documentation.

Article 19(1)ICT-related incident reporting — 4-hour initial notification

DORA requires initial notification of major ICT incidents within 4 hours of classification. MyCena’s real-time access log enables rapid assessment of which systems were accessed and by whom during an incident window — enabling faster incident classification and more accurate initial notifications.

Real-time access event log. Incident chronology export for regulatory notification. Covers all MyCena-mediated system access.

Audit evidence generated automatically by MyCena

ICT access management log

All credential issuance, scope changes, and revocation events. Supports DORA Article 9 access rights management evidence requirements.

Third-party access report

All vendor and third-party credentials: scope, issuance date, last access, revocation status. Directly supports DORA Article 28 third-party governance.

Revocation test records

Timed revocation test results with zero-access confirmation. Supports DORA Article 10 security testing requirements.

Incident access chronology

Real-time access log exportable for incident classification and regulatory notification within the 4-hour DORA window.

How to use this in a DORA review

DORA supervisors and internal audit functions focus on two things in access control reviews: can the entity demonstrate that ICT access rights are managed systematically, and can the entity demonstrate that third-party access ends when contracts end. Lead with the third-party access report — it shows every active vendor credential, its scope, and its revocation status, which is the exact evidence DORA Article 28 reviews are looking for.

ISO/IEC 27001:2022 — Information Security Management

Access Control, Authentication, and Identity Lifecycle

ISO 27001:2022 restructured the Annex A controls from 114 to 93, reorganised into four themes. MyCena addresses controls primarily within Theme 5 (Organisational controls) and Theme 8 (Technological controls), particularly the access management cluster A.5.15–A.5.18 and the authentication and privileged access controls A.8.2 and A.8.5.

Annex A controlHow MyCena addresses it

A.5.15Access control — policy and rules

ISO 27001 requires a documented access control policy and rules governing who is granted access and under what conditions. MyCena enforces the access control policy architecturally — every access grant is logged with the approving administrator, the user, the system, and the scope. Deviations from policy are structurally prevented rather than detected after the fact.

Provisioning log confirming every access grant was administrator-authorised. Scope configuration records demonstrating policy enforcement.

A.5.16Identity management — lifecycle

ISO 27001 requires management of identity lifecycle — from joiner provisioning through role change to leaver revocation. MyCena provides a complete identity lifecycle audit trail: every provisioning event, every scope change, and every revocation, with timestamps and approving administrator.

Complete identity lifecycle log per user. Joiner provisioning, role change, leaver revocation — all timestamped and administrator-attributed.

A.5.17Authentication information management

ISO 27001 A.5.17 specifically requires that authentication information — passwords and credentials — is managed securely. MyCena removes credentials from user possession entirely: no user creates, holds, stores, or transmits a credential. Authentication information is generated centrally, distributed encrypted, and injected at the point of authentication.

Architecture documentation. No credentials stored in user memory, browser, or password manager. Injection-only distribution confirmed.

A.5.18Access rights — review, modification, and removal

ISO 27001 requires periodic review of access rights, prompt modification when roles change, and removal of access when employment ends. MyCena enables all three from the same platform. Leaver revocation is simultaneous and immediate across all systems, with confirmation logged — measured in seconds, not days.

Periodic access rights review reports. Role change modification log. Leaver revocation confirmation with timestamp.

A.8.2Privileged access rights — management and monitoring

ISO 27001 A.8.2 specifically requires that privileged access rights are managed, allocated on a need-to-use basis, and monitored. MyCena applies the same central control model to privileged accounts as to standard accounts — privileged credentials are generated centrally, scoped to specific systems, and subject to the same audit logging.

Privileged access event log. Privileged credential scope records. No self-provisioned privileged credentials.

A.8.5Secure authentication — procedures

ISO 27001 A.8.5 requires secure authentication procedures including strong authentication for high-risk systems and not transmitting passwords in clear text. MyCena’s injection model means passwords are never transmitted by the user — they are injected by the platform at the point of authentication without the user ever seeing them.

Architecture documentation confirming injection-only model, no clear-text transmission to user, device binding.

A.8.3Information access restriction

ISO 27001 requires information access to be restricted to authorised users in accordance with the access control policy. MyCena enforces this restriction at the credential level — a user who does not have a credential for a system simply cannot access it. Access restriction is enforced architecturally, not through user behaviour.

Access scope records per user. No credential exists for unauthorised system-user combinations.

Audit evidence generated automatically by MyCena

Identity lifecycle log

Complete A.5.16 evidence: joiner provisioning, role changes, leaver revocation — all timestamped and administrator-attributed.

Access rights review report

Per-user, per-system access scope at any point in time. Supports periodic A.5.18 access rights reviews.

Privileged access log

All privileged account access events with full attribution. Supports A.8.2 privileged access monitoring.

Authentication architecture documentation

Technical documentation confirming A.5.17 and A.8.5 compliance — injection-only model, no user-held credentials.

How to use this in an ISO 27001 certification audit

ISO 27001 certification auditors review both documentation and evidence of implementation. For access control controls — A.5.15 through A.5.18 — the most common finding is the gap between documented policy and demonstrated practice. MyCena closes that gap: the policy is enforced by the platform’s provisioning workflow, and the audit log demonstrates it has been enforced for every access event in the audit period.

PCI DSS v4.0 — Payment Card Industry Data Security Standard

Restrict Access to System Components and Cardholder Data

PCI DSS v4.0 (mandatory from March 2025) significantly strengthened Requirements 7 and 8 — access control and authentication. MyCena directly addresses the most frequently cited PCI DSS findings: shared credentials, weak authentication, lack of unique user identification, and failure to promptly revoke access for terminated personnel.

RequirementHow MyCena addresses it

Req 7.2.1Access control model — least privilege and need-to-know

PCI DSS requires access to system components to be limited to the minimum necessary. MyCena enforces least privilege at the credential level — credentials are scoped per user per system at issuance. A user cannot access a cardholder data environment system unless explicitly provisioned for that specific system.

Per-user, per-system credential scope records. No user has credential access to CDE systems beyond their provisioned scope.

Req 8.2.1User IDs — unique ID for each user

PCI DSS Requirement 8.2.1 explicitly requires that all users are assigned a unique ID. MyCena enforces this structurally — credentials are generated per user per system. Shared credentials are architecturally impossible: no two users share a credential in a MyCena-managed environment.

Credential issuance records confirming unique credential per user-system pair. Access log showing single-user attribution for every event.

Req 8.3.1Authentication factors — strong authentication for non-console access

PCI DSS v4.0 requires multi-factor authentication for all non-console access to the CDE. MyCena complements MFA implementations by governing the credential layer that MFA verifies. The underlying credential is cryptographically strong, unique per system, and cannot be extracted from user knowledge.

Architecture documentation confirming MyCena governance of the credential layer. MFA integration records where applicable.

Req 8.2.4User accounts — inactive account management

PCI DSS requires inactive accounts to be locked or removed promptly. With MyCena, when a user is offboarded or an account is deactivated, their credential is revoked instantly across all CDE systems. There is no period during which the credential remains valid in the user’s possession.

Account revocation log with timestamp. Post-revocation blocked access confirmation. Zero active credentials for deactivated accounts.

Req 8.6.1System and application accounts — managed and monitored

PCI DSS v4.0 significantly expanded requirements for system and application account management. MyCena applies the same central credential governance to system accounts as to human users — every service account credential is generated centrally, scoped, and revocable. System account credentials are not hardcoded — they are injected at runtime.

System account credential management records. No hardcoded credentials in configuration. Runtime injection logs for automated processes.

Req 10.2.1Audit log — all individual access to cardholder data

PCI DSS requires audit logs capturing all individual user access to cardholder data and CDE systems. MyCena generates a comprehensive, tamper-evident access log for every MyCena-mediated access event — user identity, system, timestamp, device, and source IP. Exportable in standard formats.

Complete CDE access audit log: user, system, timestamp, device, IP. Exportable in QSA-compatible formats.

Req 7.3.1Access control system — managing access to all system components

PCI DSS v4.0 requires an access control system that manages and enforces access to all system components. MyCena provides this at the credential layer — every system component connected to MyCena has its access governed centrally, with no user-held credentials that bypass the control.

Connected system inventory. Credential governance records for all CDE system components. No bypass paths documented.

Audit evidence generated automatically by MyCena

Unique user access log

Req 8.2.1 evidence: every CDE access event attributed to a single named user. No shared credentials possible.

Account revocation log

Req 8.2.4 evidence: terminated account revocation with timestamp and post-revocation blocked access confirmation.

CDE access audit log

Req 10.2.1 evidence: complete cardholder data system access log in QSA-compatible export format.

System account records

Req 8.6.1 evidence: service and application account credential management, no hardcoded credentials, runtime injection logs.

How to use this in a PCI DSS QSA assessment

PCI DSS QSAs assess both the design and operating effectiveness of controls. The most common findings in Requirement 7 and 8 reviews are shared accounts, delayed offboarding, and the inability to demonstrate that terminated users lost access promptly. MyCena provides structural evidence for all three: the unique user access log demonstrates no sharing, the revocation log with timestamps demonstrates prompt termination, and the CDE access audit log supports Requirement 10 evidence collection.

CMMC 2.0 — Cybersecurity Maturity Model Certification

Access Control Domain — Protecting Controlled Unclassified Information

CMMC 2.0 is mandatory for US Department of Defense contractors handling Controlled Unclassified Information (CUI) or Federal Contract Information (FCI). Level 2 — the most common requirement — is based on NIST SP 800-171 Rev 2. MyCena addresses the Access Control (AC) domain directly, which is the most frequently assessed and most commonly deficient domain in CMMC assessments.

Practice / controlHow MyCena addresses it

AC.L1-3.1.1Authorised access — limit to authorised users and processes

CMMC requires access to systems containing FCI/CUI to be limited to authorised users. MyCena enforces this at the credential level — no user can access a CUI system unless explicitly provisioned by an administrator. There are no user-created credentials and no credential that could be shared with an unauthorised user, since credentials are never in user possession.

Credential provisioning log confirming every CUI system access is administrator-authorised. No self-provisioned or shared credentials.

AC.L1-3.1.2Transaction and function control — limit to authorised transactions

CMMC requires limiting system access to the types of transactions and functions that authorised users are permitted to execute. MyCena’s per-system credential scoping enforces this — a user’s credential grants access to a specific system with a defined scope. Lateral movement using a compromised credential is constrained because each system requires its own separately provisioned credential.

Per-system credential scope records. Access event log showing system-specific access attribution.

AC.L2-3.1.5Least privilege — non-privileged accounts for non-privileged activities

CMMC Level 2 requires the principle of least privilege. MyCena enforces least privilege by scoping every credential to specific systems at issuance. Users cannot escalate their own access — privilege escalation requires administrator provisioning of a new scoped credential.

Privilege differentiation in credential scope records. No user-escalated access events in the access log.

AC.L2-3.1.6Least privilege — use of privileged accounts for privileged functions only

CMMC requires privileged accounts to be used only for privileged functions. MyCena’s credential model enforces this by design: a privileged credential is scoped to specific privileged functions and systems. It cannot be used for general access because it is not a general credential. Privileged access events are logged separately and independently auditable.

Privileged credential usage log. Privileged access events in audit log separated from standard access events.

AC.L2-3.1.7Least privilege — prevent non-privileged users from executing privileged functions

CMMC requires prevention of non-privileged users from executing privileged functions. MyCena prevents non-privileged users from accessing privileged systems by not provisioning them with credentials for those systems. A user without a MyCena credential for a privileged system simply cannot authenticate to it — the prevention is architectural, not behavioural.

Credential scope records confirming no standard users hold credentials for privileged systems. Blocked access attempt logs where applicable.

IA.L2-3.5.3Multi-factor authentication — for local and network access to CUI systems

CMMC Level 2 requires MFA for all local and network access to systems containing CUI. MyCena complements MFA implementations by governing the credential that MFA verifies. The combination provides two distinct layers: MFA verifies the user’s identity, and MyCena ensures the credential is organisation-generated, unexposed, and unphishable.

MFA integration documentation. MyCena credential governance records demonstrating the credential layer beneath MFA.

AU.L2-3.3.1Audit logging — create and retain logs for monitoring and investigation

CMMC requires audit logs to be created and retained for sufficient time to support monitoring, analysis, and investigation. MyCena’s access event log provides a complete, tamper-evident record of all access to MyCena-managed systems — user, system, timestamp, device, IP. Logs are retained and exportable in formats suitable for SIEM integration and CMMC assessment review.

Complete access audit log with retention records. SIEM export capability. Covers 100% of MyCena-mediated CUI system access.

Audit evidence generated automatically by MyCena

Authorised access log

AC.L1 evidence: every CUI system access is administrator-provisioned and logged. No self-provisioned or shared credentials.

Privileged access records

AC.L2-3.1.5–3.1.7 evidence: privileged credentials scoped separately, privileged access events independently logged.

Complete audit log

AU.L2-3.3.1 evidence: full access event log with retention, exportable for CMMC assessment and SIEM integration.

Credential scope records

Per-user, per-system access scope. Supports least-privilege demonstration across all AC domain practices.

How to use this in a CMMC assessment

CMMC assessors evaluate both the existence and operation of practices across all 14 domains. The Access Control domain — 22 practices at Level 2 — is the most commonly deficient in self-assessments and third-party assessments alike. MyCena addresses the AC domain practices most frequently cited as deficient: credential sharing, lack of least privilege enforcement, failure to revoke access promptly, and absence of a complete audit trail. When preparing a System Security Plan (SSP) and Plan of Action and Milestones (POA&M), MyCena’s access log and credential scope records provide the artefacts an assessor needs. Lead with these in your evidence package.