Notifications
Clear all
Topic starter
24/06/2026 7:08 pm
TL;DR: Super Bowl advertising creates traffic surges that can crash brand sites and streaming properties, and DigiCert points to secondary DNS, failover, and DDoS monitoring as the practical defenses. The broader lesson is that identity and access teams must treat availability controls as part of trust architecture, not an afterthought.
NHIMG editorial — based on content published by DigiCert: 2022 Super Bowl Ads - How Brands Can Protect their Investment
By the numbers:
- In 2022, brands dish out a staggering $6.5 million to air during the big game.
- Super Bowl commercials in 1967 went for $37,500 for a 30-second spot.
- Last year's game still saw 96.5 million viewers, 65% of which were from streaming.
Questions worth separating out
Q: How should teams protect high-traffic brand sites from event-day outages?
A: Use redundant DNS, pre-tested failover paths, and clear response ownership before the traffic spike arrives.
Q: Why do single-DNS setups fail during major audience surges?
A: They create one authoritative path for every request, so any provider fault or overload can interrupt access across the entire experience.
Q: How do security teams know whether traffic anomaly detection is working?
A: It is working when it identifies abnormal spikes early enough for the team to intervene before customer sessions fail or origin capacity is exhausted.
Practitioner guidance
- Build secondary DNS into every revenue-critical domain Use a secondary provider or a primary-primary model for campaign and streaming domains so one DNS failure cannot remove the service path.
- Pre-stage DNS failover for origin outages Define backup resources and routing rules for the domains that support ad campaigns, ticketing, or live streaming.
- Baseline traffic by event window and alert on anomaly shifts Separate normal build-up from suspicious spikes by setting pre-event baselines for volume, geography, ASN, and request timing.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of secondary DNS and primary-primary deployment options for availability protection
- Operational description of DNS failover behaviour when a primary resource becomes unavailable
- Examples of DNS-level filtering by region, city, ASN, and IP address for blocking suspicious traffic
- Discussion of monitoring signals used to detect traffic anomalies before visible service impact
👉 Read DigiCert's blog on Super Bowl traffic protection for brand domains →
Super Bowl traffic spikes: what IAM and DNS teams should fix?
Explore further
25/06/2026 4:17 am
Availability governance is part of identity governance. Campaign traffic, streaming access, and branded microsites often depend on service identities, DNS authority, and automated protection layers that are treated as infrastructure details until they fail. In practice, those components define who can reach what under peak demand, so resilience has to sit inside the identity conversation, not beside it. Practitioners should treat access continuity as a governance outcome, not just an uptime metric.
A few things that frame the scale:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
A question worth separating out:
Q: Who is accountable when a campaign outage interrupts customer access?
A: Accountability usually sits across DNS operations, application owners, and the business team that approved the launch window. The key is to assign response authority before the event so technical mitigation and customer communication do not wait for a chain of escalations. Frameworks like the NIST Cybersecurity Framework 2.0 support that shared governance model.
👉 Read our full editorial: Super Bowl traffic resilience exposes the limits of single-DNS design
