A metro fiber consortium carries traffic for several cities. One network team proposes skipping encryption on overlays because 'the underlay fiber is private.' Which conclusion is correct?

Calling metro fiber private does not make every technician, tenant, or intermediate system on that glass a member of your trust domain. When underlay transport is multi-tenant or third-party operated, municipal traffic can still be exposed to misconfiguration, lawful or unlawful interception risk, or lateral visibility that the city does not control. Encryption and authentication on overlays or higher layers restore confidentiality and integrity under city-controlled keys, so security does not depend on assuming the underlay is benevolently exclusive. Trust in transport must be earned through controls you operate, not slogans about private fiber.

Claiming private fiber underlays always provide confidentiality equivalent to application-layer encryption overstates physical and contractual isolation and fails when fiber is shared, mismarked, or tapped. Refusing overlay encryption because double encryption supposedly breaks routing confuses optional nested protection with a protocol impossibility—routing continues; performance tradeoffs are manageable design choices. Limiting encryption only to guest Wi-Fi while declaring fiber underlays out of CISSP scope ignores that sensitive municipal payloads often traverse those underlays most of all.

Exam caveat: CISSP repeatedly warns against trusting the network path alone. Defense in depth applies to WAN and metro transport: encrypt sensitive flows when the underlay is not fully city-controlled.

Operational check: inventory which city flows ride consortium fiber; apply IPsec, MACsec, TLS, or application encryption per data sensitivity; review consortium tenancy and demarcation; and verify keys and certificates are city-managed rather than left to underlay convenience defaults.