Questions about
credential control

The credential control gap is the architectural space between who you are (verified by identity tools like IAM, SSO, and MFA) and what you hold (the actual credential that grants access). Every security tool deployed in the last 30 years operates at the identity layer — it verifies that the right person is presenting a credential. None of them control who generates that credential or whether it can be stolen before it is presented.

When an employee creates a password, that password exists in their memory, on their device, and potentially in a password manager they control. An attacker who obtains that credential before it reaches the authentication layer can authenticate as a legitimate user — and every verification tool will confirm the login as valid. That is why 81% of breaches succeed despite extensive identity and security investment.

All three breaches used valid credentials — logins that every security tool in place verified as legitimate. The credential was real. The session was real. The access was normal. The tools did exactly what they were designed to do: verify that the person presenting the credential had the right to access the system.

In every case, the failure occurred before verification: the credential was created by a human, held by a human, and could be obtained by an attacker without triggering any existing detection. M&S: a third-party contractor held a credential to M&S systems — M&S had no visibility of it and could not revoke it. Colonial Pipeline: an inactive account credential was never revoked after the employee left. SolarWinds: a vendor build credential existed that no one in the organisation knew about.

All three entry points are closed by credential control — not because a detection system would have flagged the login, but because the credential would not have existed in human hands in the first place.

It means exactly what it says. When MyCena is deployed, the organisation generates every credential centrally. The employee never creates a password. They are provisioned through the MyCena platform, and when they need to access a system — any system in scope — they click to connect. MyCena injects the credential at that moment, invisibly, without displaying it to the user.

The employee accesses everything they currently access. Their experience changes in one way only: they no longer type a password. Under the surface, MyCena has generated a cryptographically strong credential, distributed it encrypted, and injected it at the point of authentication. The user never sees it, never stores it, never knows it. It cannot be phished because there is nothing to enter on a fraudulent page. It cannot be shared because there is nothing to share. It cannot persist after departure because the organisation revokes it — not the user.

Phishing prevention is one outcome, but it describes only one of the three credential claim types MyCena addresses. The full scope is: phishing and social engineering (~44% of credential incidents), shared and stolen credentials (~28%), and inactive account access (~29%).

Phishing fails because the credential is never typed — the phishing page has no target. Sharing fails because the user never sees the credential — there is nothing to copy, forward, or sell. Inactive account access fails because the organisation revokes every credential in seconds when someone leaves — there is nothing left active for an attacker to find.

These are not three separate features. They are three consequences of the same architectural decision: the organisation generates and controls the credential rather than the user.

The employee authenticates once to the MyCena platform — typically with biometric or hardware token, the same way they unlock their device. From that point, every system they access through MyCena appears as a clickable connection. They click. MyCena injects the credential. They are in.

The credential is distributed to the device in encrypted form. At the moment of connection, MyCena decrypts it locally and injects it into the authentication protocol for that system. The browser or application never displays it. It is never written to the clipboard. It is never stored in the user's profile. The injection happens below the application layer — invisible to the user, invisible to any screen recording or shoulder-surfing attempt.

For different protocol types — RDP, SSH, HTTPS applications, legacy systems — MyCena uses the appropriate injection method. The employee experience is identical regardless of the underlying protocol: one click, connected.

Because the organisation generated every credential through MyCena, the organisation holds a complete record of every credential issued, to every user, for every system. When someone leaves, an authorised admin issues a single revocation command. MyCena revokes every credential for that user across every system simultaneously — within seconds.

This is not a checklist. It is not a process that depends on IT knowing which systems the person accessed. The access map is maintained automatically as credentials are issued. Nothing is missed because nothing was ever outside MyCena's visibility.

The revocation event is logged automatically with a timestamp and the identity of the authorising user. That log is immediately available for regulatory submissions, client audits, and insurance evidence. The entire process — from departure confirmed to full revocation with timestamped proof — takes under ten seconds.

The same architecture applies to AI agents and automated processes. Rather than a developer creating an API key or service credential and storing it in a config file, MyCena generates the credential centrally and injects it when the agent authenticates. The agent accesses the system. The credential is never in the config file, never accessible to the developer who built the agent, and is revoked when the agent is decommissioned.

Non-human identities now outnumber human users 82:1 in enterprise environments. 97% carry excessive privileges. 71% are never rotated. The governance gap for AI agents is structurally identical to the human credential gap — credentials created by individuals, stored outside organisational control, and left active after the agent is retired. MyCena closes both gaps on a single platform.

MyCena holds granted patents in the United States and Europe covering the core credential control mechanism: central generation, encrypted distribution, invisible injection at the point of authentication, and zero user knowledge of credential content.

The patent matters for two practical reasons. First, it confirms technical specificity — this is an examined, granted mechanism, not a policy claim or a marketing assertion. The credential physically cannot reach the user because the architecture prevents it, and that mechanism has been reviewed and validated. Second, it means no other vendor can replicate this architecture without licensing the patent. The consistency of the technical standard across MyCena deployments is architecturally enforced, not organisationally dependent.

MyCena supports the full range of authentication protocols used in enterprise and operational environments: HTTP/HTTPS web applications, RDP (Remote Desktop), SSH, VPN gateways, legacy terminal systems, SaaS applications, and client-server applications. Both Windows and macOS clients are supported.

For systems outside the standard protocol set — legacy applications with custom authentication, on-premise systems with proprietary login mechanisms — the MyCena team conducts a pre-deployment compatibility assessment. The two-week deployment timeline assumes standard enterprise systems. Legacy-heavy environments may require additional time for edge-case systems.

For a specific compatibility assessment against your environment, contact us for a pre-deployment technical review — this is included in the proof of value process at no cost.

MFA and MyCena operate at different layers and are complementary. MFA verifies that the person presenting a credential is who they claim to be — it adds a second factor to the identity verification process. MyCena operates one layer below: it governs whether the credential the person is presenting can be stolen, shared, or phished in the first place.

When an employee types their password on a phishing page, the attacker captures it. They then pass the MFA challenge (often via attacker-in-the-middle techniques that capture session tokens, or by prompting the employee to approve a notification). MFA sees a valid credential plus a valid second factor. It has no mechanism to know the credential was obtained fraudulently.

With MyCena deployed, the employee never types the credential — so it cannot be captured on a phishing page. There is nothing for the attacker to obtain. MFA continues to provide identity verification. MyCena eliminates the attack surface MFA cannot address.

No. MyCena is complementary to SSO and identity providers, not a replacement. SSO platforms like Okta and Microsoft Entra ID solve a genuine problem: they centralise authentication across applications, reduce password fatigue, and simplify lifecycle management. They are excellent at what they do.

What SSO does not govern is the underlying credential used to authenticate to the SSO platform itself, or the credentials for systems outside the federation scope. The Okta 2022 breach is the clearest illustration: a support contractor's credential — outside Okta's own authentication scope — was the entry point. Okta's platform verified the attacker as a legitimate user because the credential was real.

MyCena closes the gap SSO leaves: the credentials your employees use to authenticate to SSO, the systems outside federation scope, third-party access, and legacy applications. Okta governs what you can access. MyCena governs the key you use to enter.

PAM (Privileged Access Management) tools like CyberArk and BeyondTrust govern privileged accounts — IT administrators, system engineers, and other users with elevated access rights. They are excellent for the privileged user population and typically cover 5–10% of an organisation's users.

The credential gap that causes 81% of breaches is not primarily a privileged account problem. M&S was breached via a third-party contractor credential. Colonial Pipeline via an inactive standard user account. SolarWinds via a vendor build credential. None of these were privileged accounts under PAM scope.

MyCena governs the remaining 90–95% of users — the general workforce, contractors, BPO agents, and AI agents that PAM was never designed to cover. The two tools operate at different user tiers and are deployed in parallel. Organisations with PAM for privileged users and MyCena for the full workforce have credential governance coverage at every layer.

Yes. MyCena installs as a software overlay above existing Active Directory infrastructure. Active Directory continues to govern group policies, user management, and access permissions. MyCena sits above AD as the credential generation and injection layer — it does not replace AD, modify it, or require changes to your AD schema.

From AD's perspective, user accounts continue to exist as normal. MyCena intercepts the credential injection layer — when an employee authenticates to any AD-connected system, MyCena provides the credential automatically. The AD authentication succeeds normally. The employee never sees the password that AD has accepted.

Zero Trust is a governance model: assume breach, verify every request, apply least-privilege access, and micro-segment the network. It is the right framework. MyCena provides the Layer 1 control that Zero Trust assumes exists but does not enforce: the credential used to authenticate into the Zero Trust framework.

A Zero Trust architecture that verifies every request still depends on the credential being presented at authentication. If that credential has been phished, shared, or persisted after departure, Zero Trust verifies the attacker as a legitimate user. It applies least privilege to an attacker's session. It micro-segments the attacker's access. All of its controls operate on the assumption that the credential is valid.

MyCena ensures that assumption is warranted. Together, Zero Trust and MyCena provide: credential integrity at the authentication layer (MyCena) and access governance at the session layer (Zero Trust). Each necessary. Neither sufficient alone.

Two weeks is the standard deployment timeline for organisations with a typical enterprise IT environment. It includes: pre-deployment assessment (systems in scope, protocol mapping, integration points), client software installation across endpoints, credential migration (existing accounts are reprovisioned under MyCena governance — users do not need to take any action), administrator training, and go-live validation.

The two-week timeline is possible because MyCena installs as a software overlay. There are no network changes, no server changes, no Active Directory schema modifications, and no application reconfiguration. The systems employees access are unchanged. The credential generation and injection layer is added above them.

For organisations with a complex legacy estate, or large-scale deployments above 5,000 users, the timeline may extend to three to four weeks. The proof of value (POV) process covers a defined scope in two weeks and demonstrates full functionality before commitment to full deployment.

The POV is a two-week deployment on a defined scope — typically 50–200 users across one or two systems. It includes full deployment of the credential generation, injection, and revocation architecture, a live revocation demonstration (one-command, all-systems, timed), audit trail generation and review, and a measurement session at day 9 capturing the operational data (helpdesk tickets, offboarding events, access events) that forms the business case for full deployment.

At the end of two weeks, you have: verified the deployment works in your environment, seen instant revocation demonstrated live, captured the data to build the ROI case, and have timestamped audit evidence of the POV period ready for regulatory or insurer submission. The POV costs nothing beyond a commitment of IT time during deployment.

No meaningful retraining is required. The employee experience changes in one way: instead of typing a password to access a system, they click to connect. For most employees, this is a simplification rather than a complication — they access more systems with less friction.

A brief onboarding communication — typically one page explaining that the change means they will no longer need to remember or type passwords — is sufficient. The MyCena team provides this communication template as part of deployment. Administrators receive one half-day of platform training. No other training budget is required.

MyCena is deployed with high-availability architecture. The platform operates with SLA commitments aligned to enterprise requirements. In the event of a service interruption, a secure offline mode allows access to systems within the configured continuity policy — administrators define which systems are accessible during offline periods and under what conditions.

The continuity architecture is reviewed and agreed during deployment. For environments with specific resilience requirements — critical national infrastructure, healthcare, financial services — enhanced availability configurations are available. These are discussed during the pre-deployment assessment.

MyCena's architecture satisfies the access control and audit requirements of: DORA (Articles 9 and 28 — ICT access management and third-party risk governance), NIS2 (Articles 20 and 21 — access control measures and supply chain security), PCI DSS v4.0 (Requirement 8 — identity and access management), ISO 27001:2022 (A.9 access control, A.12.4 logging), SOC 2 Type II (CC6 trust service criteria), HIPAA (164.312(a)(1) and 164.312(b) access control and audit), CMMC 2.0 (AC domain), and FedRAMP Moderate (AC and AU control families).

The key distinction: MyCena satisfies these requirements architecturally, not through policy compliance. The continuous audit trail is generated as a byproduct of normal operation — not compiled before each audit. This is the difference between evidence that is always ready and evidence that requires three weeks of preparation.

Credential-based breaches are the largest single category of cyber insurance claims. Insurers are increasingly asking at renewal: how do you govern who holds credentials to your systems? Policy-based answers — "we have a password policy" or "we require MFA" — are insufficient at an architectural level.

MyCena provides structural credential governance that underwriters can verify: central generation (no user-created credentials), invisible injection (nothing to phish), instant revocation (timestamped log available for submission), and continuous audit trail (evidence ready on demand rather than prepared for renewal).

Organisations at MyCena Resilience or Governance tier have a materially different credential risk profile than the market average. Independent actuarial analysis suggests 10–40% premium reduction in the credential risk component is warranted for Level 4–5 credential governance maturity. This is discussed in the Credential Governance Assessment Standard.

NIS2 Article 20 explicitly states that management bodies can be held personally liable for infringements of cybersecurity requirements in essential and important entities. Named directors can face personal fines and temporary bans from management roles.

DORA places board-level accountability for ICT third-party risk governance. Directors who approved inadequate third-party risk arrangements face personal liability.

SEC rules (US listed companies) require 4-day disclosure of material cyber incidents. The SEC charged the SolarWinds CISO personally — not the company — for misleading investors about cybersecurity practices.

UK Companies Act s174 requires directors to exercise reasonable care, skill, and diligence. A director who was briefed on a documented credential vulnerability and chose not to act has a documented failure to meet the standard of care.

D&O insurance explicitly excludes known risks that board members failed to mitigate. A board that received a credential risk briefing and deferred action has a documented known risk — coverage for a resulting breach may be partial or denied.

Unphishability (£500/user/year) — Closes the phishing, sharing, and credential theft vectors across the full workforce. Central credential generation (D1), invisible injection (D2), and instant revocation (D3) all at Score 4 on the Credential Governance Assessment Standard. Audit trail near-complete (D3). Third-party governance at Score 3. Compliance evidence generation at Score 2. Reaches Level 4 maturity.

Resilience (£800/user/year) — Everything in Unphishability plus third-party and vendor credential governance (D5 at Score 4) and full audit trail with on-demand reporting (D4 at Score 4). Compliance evidence generation at Score 3. Reaches Level 4–5 maturity. This is the insurance premium reduction tier.

Governance (£1,000/user/year) — All six domains at Score 4. Automated compliance reporting with GRC API integration. Every evidence point generated as a byproduct of normal operation. Reaches Level 5 — Credential Control Achieved. This is the tier for regulated entities with continuous evidence requirements under DORA and NIS2.

The financial case has four components: operational savings (password reset cost eliminated — £25–70 per reset × annual volume, typically £50K–£200K/year for a 1,000-person organisation); breach cost reduction (probability-weighted expected breach cost at current governance level versus with MyCena deployed — typically £500K–£2M in expected value reduction); compliance overhead (audit preparation time, manual evidence compilation, regulatory remediation — typically £30K–£100K/year); and insurance premium (10–40% reduction in the credential risk component for Level 4–5 maturity).

The Board Risk Calculator generates a board-ready assessment specific to your sector, headcount, and current governance level in two minutes. It includes a formatted board paper you can use immediately.

Yes. MyCena has a dedicated channel programme for Managed Service Providers (MSPs) and Business Process Outsourcers (BPOs). The commercial structure differs from the direct enterprise pricing above.

For MSPs, pricing is structured per client environment rather than per engineer — reflecting the way MSPs deploy engineers across multiple client environments and the risk structure they carry. The MSP retains the margin between wholesale MyCena pricing and the service fee they charge clients for Governed Access Operations, a named managed service capability.

For BPOs, pricing reflects the per-agent, per-year model with revenue-share options available for large-scale deployments. The BPO-specific sell sheet and compliance one-pager are available on request. Contact us to discuss the channel programme specific to your organisation size and client base.