Trust, certificates, and the collapse of perimeter security

At a glance

What this is: This is an analysis of why perimeter trust no longer holds and why digital certificates now sit at the centre of scalable trust verification.

Why it matters: It matters because IAM, NHI, and device governance teams now have to manage trust as a lifecycle problem across people, services, and connected devices, not as a one-time authentication event.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read DigiCert's blog on building trust with digital certificates

Context

Perimeter-based security assumes that anything inside the boundary is trustworthy and anything outside is not. That model breaks down once staff, workloads, devices, and update channels operate continuously outside a fixed corporate edge, especially in cloud and remote-working environments where identity and trust decisions must be made dynamically.

For identity programmes, the shift is bigger than remote access. Certificates, device identities, service identities, and update trust all become lifecycle issues that need issuance, verification, renewal, and revocation, rather than static setup tasks. The practical question is how organisations maintain trust when the subject being trusted is no longer a person on a managed network, but a device, workload, or vendor-connected endpoint.

The article’s position is directionally consistent with modern identity governance: trust has to be verified continuously, not assumed because a system sits inside an old boundary. That makes certificate management and non-human identity control part of the same governance conversation.

Key questions

Q: How should security teams replace perimeter trust in cloud environments?

A: Security teams should replace perimeter trust with identity-based verification at every access decision. That means authenticating users, devices, workloads, and vendor-connected systems explicitly, then combining that with policy, posture, and lifecycle controls instead of assuming that internal network location is trustworthy.

Q: Why do digital certificates need lifecycle governance rather than one-time issuance?

A: Because certificates are trust artefacts with a beginning, a limited validity period, and an end state. If issuance, renewal, storage, and revocation are not controlled, the certificate can outlive the trust it was meant to represent and become a standing access risk.

Q: What breaks when IoT devices depend on vendor platforms outside local control?

A: What breaks is the assumption that the organisation fully governs the trust chain. Once a device depends on a vendor platform for support or updates, identity, patching, and revocation decisions extend beyond local administration, which creates blind spots if those dependencies are not tracked and governed.

Q: Who is accountable when a trusted certificate is abused to sign malicious content?

A: Accountability usually spans the team that owns certificate issuance, the team that protects the private key, and the organisation that failed to revoke or rotate the credential in time. Strong governance assigns clear ownership to each trust asset before abuse occurs, not after.

Technical breakdown

Why perimeter trust fails in cloud and remote environments

A perimeter model treats network location as a proxy for trust. That works only when users, devices, and services stay inside a managed boundary and access is relatively predictable. Once remote work and cloud services become normal, the perimeter dissolves into many short-lived connections, third-party paths, and internet-facing control points. Security decisions must then move from location-based trust to identity-based verification, because the attacker no longer needs to cross a neat boundary to become active inside the environment.

Practical implication: replace implicit internal trust with explicit identity checks for every access path, including remote users, workloads, and vendor-connected systems.

Digital certificates as identity and trust anchors

Digital certificates do more than encrypt traffic. They bind an identity to a key pair and let systems verify that a device, service, or person presents a trusted credential at the moment of connection. That makes certificates foundational for authentication, TLS, code signing, and machine trust. But the article correctly notes that certificates only work when their associated keys and lifecycle controls are managed properly. A certificate with weak issuance controls, poor storage, or no revocation path becomes a trust liability rather than a trust signal.

Practical implication: treat certificate issuance, storage, renewal, and revocation as an identity control plane, not an administrative afterthought.

IoT device trust and vendor dependency

IoT expands the trust problem because the device is often only one part of the chain. A boardroom display, camera, or sensor may depend on a vendor platform for updates, support, or additional processing, which means the organisation is trusting an endpoint it does not fully control and a remote service it may not govern directly. Weak default credentials, poor update mechanisms, and inconsistent security patching turn those devices into persistent trust gaps. The governance challenge is less about device count and more about unmanaged dependency chains.

Practical implication: inventory vendor-linked devices and require update, authentication, and revocation assurances before allowing them into trusted environments.

Threat narrative

Attacker objective: The attacker aims to abuse trusted identity material to gain durable access or distribute malicious activity under the appearance of legitimate trust.

1. Entry occurs when remote users, connected devices, or vendor-integrated endpoints operate outside the old perimeter and become accepted on trust rather than verified identity.
2. Escalation follows when weak device authentication, default credentials, or unmanaged certificates let an attacker reuse or impersonate trusted endpoints.
3. Impact comes from stolen or misused certificates being used to sign malicious updates, authenticate to systems, or extend access across cloud and IoT-connected environments.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Perimeter trust has become an assumption problem, not just a network design problem. The article captures a broader identity truth: once access moves beyond a fixed boundary, location stops being a meaningful trust signal. That forces security teams to govern trust through identity, device posture, and credential lifecycle instead of through network placement alone. The implication is that old trust models fail because they were designed for a stable edge that no longer exists.

Digital certificates now function as operational identity assets, not just encryption artefacts. Their value depends on issuance discipline, renewal hygiene, revocation speed, and the security of the private key behind them. In NHI terms, a certificate is only as trustworthy as the lifecycle that supports it, which is why certificate management belongs in the same governance conversation as service accounts and workload identity. Practitioners should treat certificates as governed identities with expiry, ownership, and offboarding requirements.

Vendor-connected IoT devices create a trust chain that exceeds local control. The organisation is not only trusting the endpoint, but also the vendor platform that updates, supports, or extends it. That is a governance problem because security assurance now spans multiple administrators, multiple lifecycles, and multiple revocation paths. The practical conclusion is that device trust cannot be assessed in isolation from the third-party trust chain behind it.

Identity trust collapses quickly when verification is delayed or incomplete. The article’s repeated emphasis on trust being built over time is correct, but in security operations the reverse is also true: one weak credential, one unmanaged device, or one unrevokeable certificate can undo years of trust building. That makes lifecycle control the decisive control plane for modern trust programmes.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• For a broader lifecycle lens, see Ultimate Guide to NHIs for visibility, rotation, and offboarding patterns that apply when trust moves beyond the perimeter.

What this signals

Trust drift: as organisations add remote access, IoT endpoints, and vendor-linked services, the governance problem shifts from border defence to trust-chain management. Certificate operations, device assurance, and non-human identity controls need to be run as a single programme, because each dependency can weaken the others.

In practice, teams should expect more pressure to prove ownership, revocation readiness, and update assurance for anything that authenticates without a human in the loop. That makes identity inventory and lifecycle evidence more valuable than ever, especially where certificate sprawl overlaps with service accounts and workload credentials.

The security takeaway is that trust is now measurable only if the organisation can explain who or what is being trusted, for how long, and under what revocation conditions. When that answer is missing, the trust model is already failing.

For practitioners

• Map trust dependencies beyond the perimeter Identify which users, devices, services, and vendor platforms currently rely on implicit internal trust. Document where identity decisions are still based on network location rather than explicit verification.
• Treat certificates as governed identities Assign owners, expiry rules, renewal checks, and revocation paths to certificates and their private keys. Include service certificates, device certificates, and code-signing certificates in the same lifecycle control model.
• Inventory vendor-linked IoT and smart devices Require a record of which devices depend on external vendor platforms for updates or support. Block devices that cannot prove patchability, credential uniqueness, or emergency revocation support.
• Align certificate operations with NHI controls Use service-account and workload-identity governance patterns for certificate-heavy environments, including ownership, offboarding, and rotation evidence. Where possible, connect this work to the Ultimate Guide to NHIs , The NHI Market.

Key takeaways

• Perimeter-based trust no longer matches how people, devices, and services actually connect.
• Certificates are identity assets that only remain trustworthy when their full lifecycle is governed.
• Organisations need trust-chain inventory, ownership, and revocation discipline before exposure becomes unrecoverable.

Key terms

• Digital Certificate: A digital certificate is a signed identity record that binds a public key to a subject such as a person, device, or service. In security operations it acts as a trust anchor, but only when issuance, renewal, storage, and revocation are controlled throughout its life.
• Trust Chain: A trust chain is the sequence of identities, systems, and assurances that must all remain valid for an authentication or update to be trusted. When one link depends on a third party or an unmanaged device, the chain becomes a governance problem as much as a technical one.
• Certificate Lifecycle: Certificate lifecycle is the full process of issuing, tracking, renewing, rotating, and revoking a certificate and its associated keys. It matters because a certificate that is technically valid but no longer governed can extend access or signing trust beyond the organisation’s intended boundary.
• Perimeter Security: Perimeter security is a model that assumes systems inside the network boundary are trusted and those outside are not. It remains useful as a concept, but in cloud, remote work, and IoT environments it can create false confidence unless paired with continuous identity verification.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Building trust in an untrusting world. Read the original.