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.
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.
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.
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.
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.
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
Ce site utilise Google Analytics pour collecter des informations anonymes telles que le nombre de visiteurs du site et les pages les plus populaires.
Garder ce cookie activé nous aide à améliorer notre site Web.