By NHI Mgmt Group Editorial TeamDomain: Cyber SecuritySource: GlobalSignPublished November 19, 2025

TL;DR: Smart city deployments expand the attack surface because connected devices, gateways, and municipal networks can be disrupted at scale if identity, authentication, and encryption are not designed in from the start, according to GlobalSign. The security lesson is that operational resilience in IoT programmes depends on device identity lifecycle control, not just network connectivity.


At a glance

What this is: This is an analysis of why smart city security depends on identity, authentication, and encryption across connected device lifecycles, with a focus on how weak design choices can create city-wide operational impact.

Why it matters: It matters to IAM practitioners because IoT and smart infrastructure depend on machine identities, certificate lifecycle control, and access governance that must be managed with the same discipline as human and NHI access.

By the numbers:

👉 Read GlobalSign's analysis of smart city IoT identity and security design


Context

Smart city programmes concentrate operational risk because they connect physical services, public infrastructure, and digital control planes. When identity, authentication, and encryption are treated as afterthoughts, the result is not just a technical weakness but a governance failure that can affect transport, utilities, public safety, and municipal communications. For identity teams, this is a machine identity and certificate lifecycle problem as much as an infrastructure one.

The article argues that security from the design stage is the difference between a manageable IoT rollout and a city-scale exposure. That framing is relevant to NHI governance because connected devices, gateways, and service components behave like non-human identities: they authenticate, authorise, and exchange data continuously, often at very high volume. The Ultimate Guide to NHIs is the natural companion resource for teams mapping these controls to lifecycle governance.


Key questions

Q: How should organisations govern identity for smart city IoT devices?

A: Organisations should govern smart city IoT identities through a full lifecycle model that covers issuance, authentication, monitoring, rotation, and revocation. Device credentials and certificates need named owners, defined expiry, and tested offboarding paths. Without that discipline, exposed gateways and unmanaged endpoints become persistent trust anchors rather than controlled assets.

Q: Why do smart city deployments create security risk so quickly?

A: Smart city deployments create risk quickly because they connect physical services to distributed device fleets, often before identity and logging controls are mature. A single weak device, gateway, or API can create a path into lighting, utilities, or communications systems. The result is operational disruption, not just a narrow technical incident.

Q: What breaks when IoT security is added after rollout?

A: When IoT security is added after rollout, organisations usually inherit inconsistent onboarding, poor revocation, and incomplete asset visibility. That makes it difficult to know which devices are trusted, which credentials are still valid, and which services can be reached. In practice, the environment becomes harder to govern than to secure.

Q: What should teams prioritise in smart infrastructure identity controls?

A: Teams should prioritise strong authentication, explicit authorisation, certificate lifecycle management, and segmentation between device and management planes. Those controls reduce the chance that one compromised device can affect the broader environment. For municipal programmes, resilience depends on controlling trust boundaries, not just connecting more devices.


Technical breakdown

Smart city IoT identity and certificate lifecycle

Smart city infrastructure depends on machines proving who they are before they can send or receive data. In practice, that means certificates, device credentials, and trust anchors must be issued, deployed, monitored, rotated, and revoked across large fleets. Public lighting, utilities, gateways, and sensors all need identity assurance because unmanaged devices can become entry points or trust shortcuts. The article’s PKI emphasis reflects a core reality: if device identity is weak, every downstream control inherits that weakness.

Practical implication: treat device certificates and service credentials as lifecycle-managed identities, not static configuration.

Why encryption and authorisation matter in connected municipal systems

Encryption protects data in transit, but in smart city environments it also protects trust in the control plane. Authorisation ensures a device can talk only to the systems and services it is supposed to reach, limiting the blast radius if a node is compromised. In city-scale deployments, authentication without strong authorisation still leaves broad lateral movement paths across gateways, management APIs, and service buses. The article correctly links confidentiality, integrity, and access control as a single design problem.

Practical implication: pair strong device authentication with explicit allowlists and least-privilege communication paths.

Why ad hoc IoT rollouts create governance debt

The article contrasts cautious, planned deployments with ad hoc adoption, and that distinction matters because security gaps compound over time. When cities pilot devices without standardised policy for onboarding, monitoring, and offboarding, they create governance debt that is hard to unwind later. That debt looks familiar to identity teams: inconsistent provisioning, weak revocation, and unclear ownership. In smart infrastructure, those weaknesses are multiplied by scale and by the physical consequences of outage or manipulation.

Practical implication: require common onboarding and offboarding controls before expanding any smart city pilot.


Threat narrative

Attacker objective: The attacker aims to disrupt essential urban services, expand control over connected infrastructure, or expose sensitive municipal and consumer data.

  1. Entry occurs when attackers target exposed devices, unmanaged gateways, or weakly protected municipal communications infrastructure in a smart city environment.
  2. Escalation follows when compromised device trust or poor network segmentation lets the attacker move from a single device into broader lighting, utility, or communications systems.
  3. Impact is city-wide disruption, including outages, traffic chaos, data exposure, or the manipulation of public services at scale.

NHI Mgmt Group analysis

Security from design is the only sane model for smart infrastructure: retrofitting controls onto deployed IoT estates almost always leaves blind spots in onboarding, certificate management, and revocation. Smart cities mix physical and digital risk, so weak identity design can produce outsized operational harm. The practical conclusion is simple: identity controls must be part of architecture decisions, not added after deployment.

Smart city device identity is an NHI governance problem in practice: connected devices, gateways, and service components behave like non-human identities that authenticate continuously and at scale. That makes lifecycle discipline, credential hygiene, and ownership clarity central to resilience. Teams that already govern NHIs can apply the same model to municipal IoT estates, especially where certificates and API credentials drive machine-to-machine trust.

Smart city identity sprawl creates a verification trust gap: the article shows how quickly trust can be lost when ad hoc rollouts outpace policy, standards, and monitoring. Once devices are deployed without consistent identity and logging controls, the organisation cannot reliably know what is connected, what is authorised, or what has been exposed. That is a governance failure, not just a technical one, and practitioners should treat it as such.

Standards are the only way to keep municipal IoT from fragmenting into exception management: the article’s references to NIST and industry groups point to a broader reality, namely that smart infrastructure needs shared control baselines. Without common policy, cities end up with inconsistent trust models across vendors, utilities, and departments. Practitioners should standardise identity, authentication, and encryption requirements across the entire fleet.

What this signals

Smart city operators should treat device trust as an identity programme, not an infrastructure afterthought: the operational pattern here is the same one seen in NHI sprawl. Once devices, gateways, and service accounts scale faster than ownership and revocation, visibility collapses and risk becomes cumulative.

Municipal programmes that already use certificate-based trust should map those assets to a named lifecycle owner, expiry policy, and revocation test. The practical signal is whether the organisation can answer, in minutes rather than days, which devices are trusted and which are still able to authenticate.

The strongest programmes will standardise identity controls across utilities, transport, and public safety systems instead of allowing each deployment to invent its own trust model. That approach reduces exception handling and makes incident containment materially easier when a device or gateway is compromised.


For practitioners

  • Standardise device onboarding and offboarding Create a mandatory onboarding workflow for every smart city device, including identity proofing, certificate issuance, asset registration, and a defined offboarding path for decommissioning or compromise. This reduces orphaned devices and makes revocation operationally possible.
  • Rotate and revoke machine credentials on a fixed schedule Set certificate and key rotation requirements for gateways, sensors, and management services, and test revocation as part of incident response. If a device credential cannot be revoked quickly, it is a standing trust risk.
  • Segment municipal control planes from device networks Separate management APIs, operational networks, and public connectivity paths so a compromised node cannot easily reach the rest of the environment. Use explicit allowlists for device-to-service communication and log every privilege boundary crossing.
  • Align smart city identity controls to NHI governance Map certificates, API keys, and device identities to the same ownership, review, and lifecycle model used for other non-human identities. For background, the Ultimate Guide to NHIs is useful for translating lifecycle controls into operational policy.

Key takeaways

  • Smart city security fails when identity, authentication, and encryption are treated as add-ons instead of design inputs.
  • The scale of the risk is operational, because a single device or gateway weakness can affect public services, not just one endpoint.
  • Practitioners should manage device certificates, authorisation paths, and offboarding as lifecycle controls within a broader NHI governance model.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Identity and access control are central to smart city device trust.
NIST SP 800-53 Rev 5IA-5Credential lifecycle management is core to device certificate governance.
MITRE ATT&CKTA0006 , Credential Access; TA0008 , Lateral MovementCompromised devices can be used to steal trust and move across municipal systems.
OWASP Non-Human Identity Top 10NHI-03The article's device identity lifecycle issues align with non-human credential rotation.
NIST Zero Trust (SP 800-207)Zero trust principles fit segmented device-to-service communication in smart infrastructure.

Use zero trust segmentation to verify each device-to-service request before access is granted.


Key terms

  • Machine Identity: A machine identity is the set of credentials and trust attributes a device or service uses to authenticate itself to other systems. In smart infrastructure, this is usually certificate-based and must be managed through issuance, rotation, revocation, and ownership just like any other privileged identity.
  • Certificate Lifecycle Management: Certificate lifecycle management is the process of issuing, tracking, renewing, rotating, and revoking digital certificates over time. It matters because expired or unrevoked certificates can create silent trust failures or persistent access paths across large IoT environments.
  • Trust Boundary: A trust boundary is the point at which one system must stop assuming another system is safe and instead verify identity and permission. In smart cities, trust boundaries exist between devices, gateways, management planes, and service networks, and they need explicit control rather than implicit trust.

What's in the full article

GlobalSign's full post covers the operational detail this post intentionally leaves for the source:

  • How the PKI-based identity platform is used to issue and manage device identities across the full lifecycle.
  • How the article frames authentication, authorisation, and encryption as a single security model for smart cities.
  • How GlobalSign positions its IoT identity platform within broader smart city and utility ecosystems.
  • How the article connects industry groups and standards bodies to large-scale IoT adoption.

👉 GlobalSign's full post covers the PKI identity model, standards context, and smart city risk scenarios.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to translate identity lifecycle principles into operational control.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org