One Weak Key, One Exited Market: What the eMudhra Episode Teaches Us About Shift-Left Security

This week, the Indian digital-trust provider eMudhra said it would voluntarily pull out of the global SSL/TLS certificate business. Google, Apple, Microsoft and Mozilla moved to block or distrust certificate chains it had issued, India's CERT-In put out an advisory, and the company's shares reportedly fell about 40% over two trading days.

This story is worth a pause, and not because of a dramatic breach. eMudhra says its infrastructure was not compromised and no data was breached. From what's been published so far, nobody stole anything. The problem was created much earlier, quietly, at the very start of the lifecycle. That makes it one of the clearest recent cases for shift-left security.

What went wrong at eMudhra: weak intermediate CA keys

An independent researcher found that several of eMudhra's intermediate CA keys were weak. Reports describe them as "too small and predictable" to give the expected cryptographic protection, so private keys could be rebuilt from information in the public certificates. eMudhra withdrew eight intermediate certificates. Those keys were reportedly generated during a key ceremony in April 2025.

Read that timeline again. A flaw created at the start stayed in production for over a year, trusted by every major browser, until someone outside the company found it. When it came to light, no patch could fix it. The only fix was revocation, distrust, and, in the end, leaving the market.

The business was only about 1% of revenue. The market didn't react to that 1% because trust doesn't work in percentages.

The lesson: some security flaws can't be fixed after the fact

We often talk about security as detection and response: find the attacker, contain the damage, recover. That model matters, but it has a blind spot. Some weaknesses are locked in the moment something is created:

• A key generated with too little randomness (entropy) or the wrong parameters
• A cloud role created with wildcard permissions "just for now"
• A service account created with long-lived credentials and no owner
• A certificate, token or secret issued without any policy checks

None of these sets off an alert on day one. They sit there as hidden risk until a researcher, an auditor or an attacker finds them. By then every option is expensive: rotate everything, revoke trust, rebuild, explain.

That is the case for shift-left security: check things when they are created, not when someone discovers the problem.

What shift-left security looks like in practice

Shift-left is often treated as a developer-tooling idea, like scanning code before it merges. It should go much further, especially for anything that carries trust: keys, certificates, identities, and permissions.

1. Policy at creation, not review after. Enforce rules on key sizes, permission scopes, and credential lifetimes when an identity or credential is created, not in a quarterly audit.
2. Independent checks on critical ceremonies. High-trust operations need automated, repeatable checks that don't rely only on the people doing the work.
3. Continuous posture checks. "It was fine when we set it up" isn't a control. Settings drift, standards change, and what was acceptable last year may be weak today.
4. Give machine identities the same attention as people. Certificates, API keys, service accounts and workload identities now far outnumber human users in most environments, yet they often get the least oversight.
5. Find it before an outsider does. If an outside researcher is how you find your problems, your security program is running backwards.

Why we built Unosecur this way

At Unosecur, this is exactly the problem we set out to solve. Identity, both human and non-human, is the real perimeter. Most identity risk is created long before anyone exploits it: an over-permissioned role, an orphaned service account, a stale or overly broad credential, a misconfiguration nobody noticed.

We built Unosecur around a shift-left, preventive approach to identity security. We don't wait to spot damage after the fact. With its Unified Identity Fabric, Unosecur continuously discovers identities and permissions across cloud and SaaS environments, flags risky settings and excess privileges as they appear, and helps teams fix them before they turn into an incident, an advisory or a headline. Detection and response still matter, and we do that too. But the cheapest incident is the one that never gets the chance to happen.

The takeaway: trust is won or lost at creation

The eMudhra episode is a reminder that trust is built, and lost, at the moment something is created. Every key, certificate, and identity your organization issues is a promise. Checking that promise at the start costs a fraction of what it costs to revoke it later.

So ask yourself: if a flaw slipped into one of your identities or credentials today, who would find it first, your team or someone else?