A website attack has no relationship to the clock in your particular time zone. A DDoS attempt doesn’t wait for your support provider’s office to open; a brute-force script doesn’t check what time it is in the region where a company happens to be headquartered. This is a genuinely practical problem in emergency security support, and it’s worth talking about directly rather than glossing over with vague “24/7 support” language that most hosting marketing leans on without explanation.

The Real Problem With Single-Region Support

A lot of hosting and security providers are built around a single region’s business hours, with an “emergency” line that’s really just a queue that gets attention once the home office wakes up. For a business whose customers, traffic, and — most relevantly — attackers, aren’t confined to one time zone, that gap between “the incident started” and “someone competent is actually looking at it” can be the entire difference between a contained situation and a full outage.

This isn’t a knock on any specific provider — it’s just a structural reality of how a lot of hosting companies are built, growing from a local base and expanding support second.

Where Tremhost’s Footprint Actually Comes From

Tremhost’s positioning — “Built in Africa, trusted globally, Harare to Houston, Nairobi to NYC, London, Dubai, Singapore” — isn’t just a tagline for marketing copy. It reflects a genuinely distributed customer base and operational reality: sites and businesses spread across multiple continents, which means incidents don’t cluster conveniently into one region’s working hours. A brute-force attempt against a Nairobi-based ecommerce store and a DDoS attempt against a Houston-based SaaS product aren’t going to politely take turns during one office’s 9-to-5.

What This Means Practically for Emergency Response

Being built around a genuinely global customer base from the outset shapes how emergency response actually has to work — not as an add-on “we also cover other time zones” feature, but as a baseline assumption in how the service is structured. When an Armor SOS emergency comes in, the response isn’t dependent on which specific hour it happens to be in one particular headquarters city.

Why This Matters More for Emergencies Than Routine Support

For a routine support ticket — a billing question, a general how-to — a delay of a few hours is an inconvenience. For an active security incident, the same delay is a completely different category of problem: it’s the gap between an attack being caught in its early, containable stage versus discovered only after significant damage, downtime, or data exposure has already occurred.

This is really the core argument for why “emergency support” as a phrase needs to mean something specific and structural, rather than being a generic reassurance layered onto a support system built for a single region’s convenience.

Global Reach, Local Understanding

There’s a second, less obvious advantage to operating across this many regions: exposure to a genuinely wide range of hosting environments, attack patterns, and regional infrastructure quirks — from ISPs and connectivity conditions in different parts of the world, to the kinds of attack traffic that tend to originate from or target specific regions. A provider that’s only ever dealt with one region’s typical traffic patterns has a narrower frame of reference than one that’s regularly handling incidents across genuinely different environments.

What This Looks Like From the Customer Side

The practical takeaway, stated plainly: when something goes wrong with your site, the response isn’t gated behind “wait until it’s morning somewhere specific.” Whether the incident happens to align with business hours in Harare, London, or Singapore is not the deciding factor in whether your site gets emergency attention.

“Emergency security support” is one of those phrases that shows up constantly in hosting marketing and rarely gets explained. It sounds reassuring, but if you’re the one actually deciding whether to pay for it — especially mid-crisis, when your site is already down — a vague promise isn’t good enough. So instead of another marketing summary, here’s a literal, line-by-line breakdown of what’s actually included in Tremhost Armor SOS, and why each piece exists.

Line Item 1: Emergency DNS Cutover to Cloudflare (Same-Day)

What this means in practice: if your site currently has no proxy protection at all — traffic going directly to your server with nothing filtering it — this is the process of routing your domain’s traffic through Cloudflare instead, on the same day the emergency is happening, rather than the multi-day timeline of a standard, unhurried migration.

Why it’s a distinct line item: a normal DNS/proxy setup is deliberately paced to avoid misconfiguration. Doing it safely and quickly, under pressure, while a site may already be struggling, is a different skill than doing it carefully over several days — which is why this isn’t just “the same service, faster.”

Line Item 2: Under Attack Mode Activation

What this means in practice: once traffic is routed through Cloudflare, this specific setting adds a brief automated verification step in front of every visitor before they reach your site — filtering out much of the automated, script-driven traffic typical of an active attack.

Why it’s a distinct line item: this isn’t switched on by default even with a standard Cloudflare setup, because it does add a small amount of friction for legitimate visitors — it’s a deliberate, situational trade-off made specifically when a site is actively under pressure, not a permanent setting.

Line Item 3: Emergency WAF and Rate-Limiting Rules

What this means in practice: rather than deploying generic, one-size-fits-all firewall rules, this is building rules specific to what’s actually happening to your site right now — if it’s a login brute-force, rate limiting goes directly on the login endpoint; if it’s XML-RPC abuse, that specific vector gets closed.

Why it’s a distinct line item: generic rule sets can miss the specific attack pattern happening in the moment, or worse, block legitimate traffic unnecessarily. Custom, situation-specific rules take deliberate configuration — this is diagnostic work, not a template being applied.

Line Item 4: Origin IP Rotation (If Compromised)

What this means in practice: if there’s reason to believe your server’s real IP address is already known to an attacker, this replaces it with a new one and ensures every path to your site goes through the proxy going forward — closing the direct route that would otherwise let attackers bypass all of the above protections entirely.

Why it’s a distinct line item: this step is only necessary when there’s evidence of exposure, but when it is needed, it’s the difference between protection that’s genuinely effective versus protection that looks complete on paper while a known bypass still exists.

Line Item 5: Post-Incident Summary

What this means in practice: a clear, written account of what happened and exactly what was changed — not a log dump, a readable summary covering the timeline, likely entry point, actions taken, and current status.

Why it’s a distinct line item: fixing a site and documenting what was fixed are two different deliverables. Without this, six months from now there’s no record to check against if something looks off again — and no clear account to give customers or auditors if one is needed.

What’s Deliberately Not Included (And Why That’s Honest, Not a Gap)

To be transparent about scope: Armor SOS is built to stabilize an active emergency, not to be ongoing protection. It doesn’t include continuous WAF tuning, monthly reporting, or quarterly reviews — those are what Armor Lite, Pro, and Business are for. Positioning a one-time emergency service as a replacement for ongoing protection would be misleading; it’s the fix for right now, not the plan for going forward.

The Full Picture in One Table

Price: $150.00, one-time.

When This Makes Sense vs. When It Doesn’t

Armor SOS makes sense if your site has no existing proxy or WAF protection and something is actively happening right now. If you already have Armor Lite or Pro running, most of this is already in place proactively — the emergency scenario this solves largely doesn’t arise in the first place, which is really the underlying point of having ongoing protection at all.

If you run an online store or process payments through your website, you’ve probably seen “PCI DSS compliant” or “PCI-ready” in hosting marketing more times than you’ve seen it actually explained. It’s one of those terms that gets used to sound reassuring without much behind it. Here’s what it actually means, what your hosting can and can’t do about it, and what “ready configuration” genuinely covers.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

What PCI DSS Actually Is

PCI DSS — the Payment Card Industry Data Security Standard — is a set of security requirements created by the major card networks (Visa, Mastercard, and others) that any business handling cardholder data has to follow. It’s not a government law; it’s an industry requirement enforced through your relationship with payment processors and acquiring banks. If your business accepts card payments, some level of PCI DSS applies to you, whether or not you’ve thought about it directly.

The Important Distinction: Compliance vs. Configuration

This is the part hosting marketing tends to blur. No hosting provider can make your business “PCI compliant” — compliance is a business-wide responsibility that includes how you handle data internally, your policies, your staff practices, and often a formal assessment specific to your business. What a host can do is provide the technical infrastructure and configuration that supports meeting those requirements — which is meaningfully different from being the whole answer.

Think of it like fire safety in a rented building: the landlord can install proper wiring, fire doors, and sprinkler systems — but whether the business itself follows fire safety procedures day to day is a separate responsibility. Good infrastructure is necessary; it’s not sufficient on its own.

What “PCI DSS-Ready Configuration” Actually Covers

When we talk about this as part of Armor Business, here’s specifically what’s meant:

• Network segmentation guidance — helping ensure systems that handle card data are appropriately separated from the rest of your infrastructure
• TLS/SSL enforcement — ensuring data in transit is properly encrypted, using current, non-deprecated protocols
• WAF rules aligned with PCI requirement 6.6 — which calls for either a code review process or a web application firewall in front of anything handling payment data
• Access control configuration — supporting the restricted-access principles PCI DSS expects around systems that touch cardholder data
• Logging and monitoring setup — since PCI DSS requires being able to track and monitor access to card data environments

What This Doesn’t Include (Said Plainly)

To be direct about the boundaries: this configuration guidance doesn’t replace a formal PCI DSS assessment if your transaction volume requires one, it doesn’t cover your internal staff policies or physical security, and it doesn’t make you compliant by itself if your business handles card data in ways outside what your hosting touches — for example, if you store card numbers somewhere other than through a compliant payment processor.

The honest, most common setup for a small business is actually simpler than people expect: using a PCI-compliant payment processor (Stripe, PayPal, etc.) so your own infrastructure never directly touches raw card numbers at all. In that case, your PCI DSS scope is significantly smaller, and the hosting-side configuration matters less than making sure that handoff to the processor is done correctly and securely.

Why This Still Matters Even With a Compliant Processor

Even when card data itself doesn’t touch your server directly, your site is still the front door — the checkout page, the redirect to your payment processor, the session handling around that transaction. If that front door is compromised, an attacker doesn’t need your card data directly; they can intercept it in transit, redirect checkout traffic elsewhere, or inject something into the checkout page itself before it ever reaches your processor. This is precisely the kind of gap a properly configured WAF and rate limiting on checkout endpoints is meant to close which is part of what’s included in Armor Pro as standard, before even reaching Business-tier compliance guidance.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

A Simple Way to Think About Where You Sit

What Armor Business Adds Specifically

Beyond the Pro-tier protections, Armor Business includes PCI DSS-ready configuration guidance as a distinct line item, alongside expanded WAF rule capacity and quarterly configuration reviews — which matter here specifically because PCI DSS isn’t a “set it once” requirement; it expects ongoing attention as your systems and transaction patterns change.

When a website gets attacked and then recovers, the natural instinct is relief — the site’s back up, the immediate crisis is over, and the temptation is to move on and not think about it again. This is exactly where a lot of businesses leave value on the table, because fixing the problem and understanding the problem are two different deliverables, and only one of them prevents a repeat.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

Why “It’s Back Up” Isn’t the Same as “It’s Resolved”

A site can be fully restored — traffic flowing normally, firewall rules in place, everything looking clean — while the actual questions that matter are still unanswered:

• What was the entry point? Was it a compromised password, an outdated plugin, an exposed origin IP, or something else entirely?
• What specifically was changed to fix it — which DNS records, which WAF rules, which credentials?
• Was any data actually accessed, or was this contained before it reached anything sensitive?
• Is the underlying vulnerability actually closed, or was this just a symptom treated without addressing the cause?

Without a clear answer to these, “the site is back up” can mean the problem is solved or it can mean the same door is still unlocked, just currently unused.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

Who Actually Needs This Report (It’s More People Than You’d Think)

You, later. Six months from now, if something looks slightly off again, a written record of exactly what happened and what was changed is the difference between quickly checking “did we already fix this” and starting an investigation from zero.

Your customers, if their data was involved. Depending on what was accessed, there may be a genuine obligation — legal or simply reasonable — to explain what happened. A vague “we had some technical issues” doesn’t hold up the way a clear, factual account does, and having the details already documented makes that conversation far less stressful when it needs to happen.

Compliance and audit processes. For any business handling payment data or operating toward PCI DSS expectations, being able to show a documented incident response — not just “we fixed it” but what was fixed and when — is often part of what auditors or payment processors actually want to see.

Anyone who takes over technical decisions later. If you ever bring on a new developer, agency, or hire, a clear incident history saves them from having to reverse-engineer your server’s configuration to understand why certain rules or settings exist.

What a Proper Post-Incident Summary Actually Includes

A useful report isn’t a wall of server logs it’s a clear, readable account covering:

This is exactly what’s included as standard with Tremhost Armor SOS not an afterthought add-on, but part of the emergency response itself. The reasoning is straightforward: an emergency fix without a record of what was fixed just moves the uncertainty from “is my site under attack” to “do I actually understand what happened to it.”

The Quiet Cost of Skipping This Step

Businesses that treat “back online” as the finish line tend to run into the same pattern later: a second incident happens, and there’s no baseline to compare against. Was this the same vulnerability again, or something new? Nobody can say for certain, because nothing from the first time was written down. This usually means the second response takes longer and costs more, simply because it’s starting from the same blank slate as the first.

A documented incident, by contrast, becomes an asset it’s the reason the second time (if there is one) becomes a quick check against a known issue rather than another full investigation.

Where This Fits Into Ongoing Security

A post-incident report is also naturally where the conversation about ongoing protection happens since the report itself usually points directly at what would have prevented the incident in the first place. If the entry point was an unpatched plugin being scanned repeatedly, that’s a conversation about Armor Pro’s custom WAF rules. If it was about PCI-relevant data exposure, that’s a conversation about Armor Business’s compliance-ready configuration.

The report isn’t just a summary of the past it’s the most accurate map available for what to do differently going forward.

“DDoS” gets thrown around constantly in hosting and security marketing, usually without anyone actually explaining what it means. If your site has ever gone down suddenly with no clear cause, or you’ve just seen the term and wondered what it actually describes, here’s the plain-English version no assumed technical background required.

The Basic Idea, in One Sentence

A DDoS attack works by sending a website far more traffic than its server can handle at once, so the server becomes overwhelmed and stops responding to anyone including your real visitors.

That’s genuinely the core of it. Everything else is detail about how that flood gets created and why it’s harder to stop than it sounds.

Why It’s “Distributed”

The “D” that comes before “DoS” (Denial of Service) stands for Distributed meaning the flood of traffic doesn’t come from one computer, it comes from thousands or even millions of devices at once, often spread across many countries. These devices are frequently ordinary computers, routers, or smart devices that have been infected with malware without their owners’ knowledge, forming what’s called a botnet.

This is why blocking “the attacker’s IP address” doesn’t work as a defense there isn’t one attacker’s IP, there are potentially millions of them, each sending a small amount of traffic that adds up to an overwhelming total.

What Your Server Actually Experiences

Think of your web server like a single checkout counter at a store, built to comfortably handle a normal flow of customers. A DDoS attack is the equivalent of tens of thousands of people suddenly trying to walk through that one checkout counter at the same second. It’s not that any individual “customer” is doing anything unusual — it’s that the sheer volume physically cannot be processed, so the line stops moving entirely, and genuine customers can’t get through either.

Technically, this happens because every request to your server consumes a small amount of resources processing power, memory, bandwidth. A normal amount of traffic uses a normal amount of these resources. A flood of attack traffic exhausts them entirely, leaving nothing left to serve real visitors.

The Different “Flavors” of DDoS Attacks

Not all DDoS attacks work the same way. Broadly:

• Volume-based attacks — simply flooding your connection with as much raw traffic as possible, aiming to saturate your bandwidth
• Protocol attacks — exploiting weaknesses in how servers handle connection requests, tying up server resources with incomplete or malformed connections rather than raw volume
• Application-layer attacks — mimicking normal-looking requests (like loading a page or submitting a form) but at a volume and speed no real user could produce, which is harder to distinguish from legitimate traffic

This last category is often the trickiest to defend against, because the traffic doesn’t look obviously malicious at a glance — it looks like a lot of people visiting at once, just far too many, far too fast.

Why You Often Can’t “Just Block It” Yourself

The instinct is to think a firewall on your own server should handle this. The problem is that by the time attack traffic reaches your server, the damage is already happening your connection and resources are already being consumed. Blocking traffic at that point is like trying to control a crowd after they’ve already crammed through the door; the congestion has already occurred.

This is why effective DDoS protection works before traffic reaches your server, not after filtering and absorbing the flood at a separate layer with far more capacity than any single website’s server, so only clean traffic ever reaches your actual site.

How Proxy-Based Protection Actually Stops This

This is the core function of a service like Cloudflare sitting in front of a website: instead of traffic going directly to your server, it goes to a globally distributed network built specifically to absorb massive traffic volume, get filtered, and only pass along legitimate requests. Your server never sees the flood at all it just sees the clean traffic left after filtering.

During an active attack, Under Attack Mode adds an extra layer on top of this a brief automated check in front of every visitor, which filters out the automated, script-driven requests common in DDoS traffic while still letting real humans through with minimal friction.

Why “Unmetered” Protection Matters

One detail worth understanding: DDoS protection that caps out at a certain traffic volume defeats the purpose, since the entire nature of an attack is unpredictable, potentially massive volume. This is why unmetered DDoS protection — protection with no traffic ceiling is table stakes rather than a premium feature; it’s included as standard across every Tremhost Armor tier, from Lite through Business, because there’s no version of “DDoS protection” worth having if it can itself be overwhelmed.

What This Means Practically for Your Site

Understanding what’s actually happening during an attack makes the value of this kind of protection much less abstract it’s not a marketing checkbox, it’s the difference between traffic being absorbed upstream versus your server trying to survive a flood it was never built to handle alone.

Most WordPress attacks don’t arrive out of nowhere. There’s almost always a build-up small, easy-to-miss signals in the days or weeks before things escalate into an actual breach or outage. The problem is that these signals look like background noise unless you know what you’re looking at. Here’s what to watch for, and what’s actually happening behind each one.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

Sign 1: A Sudden Spike in Failed Login Attempts

If your WordPress login page is seeing dozens or hundreds of failed attempts in a short window, that’s not a fluke it’s almost always an automated brute-force attempt working through common username/password combinations. On its own, a modern password usually survives this. The danger is that brute-force attempts tend to escalate over time, and a login page with no rate limiting will keep letting the attacker try, indefinitely, for free.

What this looks like in your logs: repeated POST requests to /wp-login.php from a rotating set of IPs, often at a steady, mechanical interval rather than the irregular pattern of a human typing.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

Sign 2: Unusual Activity on XML-RPC

xmlrpc.php is a WordPress file originally built to allow remote publishing and communication between sites but it’s also one of the most commonly abused entry points, because a single request to it can trigger hundreds of login attempts internally, effectively turning one request into a brute-force multiplier. If your server logs show repeated POST requests to this file, especially in bursts, that’s a strong early indicator someone is probing for weak credentials at scale.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

Sign 3: Traffic That Doesn’t Behave Like Visitors

Real visitors browse unevenly they land on a page, pause, click around, sometimes bounce immediately. Bot traffic tends to look mechanically consistent: identical time-on-page across sessions, requests hitting the same handful of URLs in sequence, or traffic arriving in perfectly even intervals rather than natural clusters. A sudden increase in “visitors” that all behave identically is a sign you’re looking at bots, not people and bots probing a site are often reconnaissance for a later, more targeted move.

Sign 4: Requests to Endpoints That Shouldn’t Get Traffic

Watch for repeated requests to things like /wp-content/uploads/, old plugin folders, or admin-adjacent paths that aren’t part of your normal site navigation. Attackers frequently scan for known vulnerabilities in outdated plugins or themes by requesting specific file paths directly — if a request pattern looks like it’s checking for the existence of files rather than viewing your actual content, that’s scanning behavior, not browsing.

Sign 5: A Slow, Unexplained Increase in Server Load

Before a full DDoS event, there’s sometimes a quieter ramp-up server response times creeping up, resource usage climbing without a corresponding rise in legitimate traffic. This can be attackers testing capacity, running smaller probing waves before a larger attempt, or bots simply crawling more aggressively than your server can comfortably handle.

Why These Signs Usually Go Unnoticed

None of this shows up on a typical site owner’s radar because none of it looks dramatic in isolation a few failed logins here, a slightly higher bounce rate there. It only becomes obvious in hindsight, after the full attack, when someone finally looks back at the logs and realizes the warning signs were all there a week earlier.

What Armor Pro Catches Automatically

This is precisely the gap between hoping nothing happens and having something actively watching:

Every month, Armor Pro also includes a one-page security and traffic report — which means these patterns don’t just get blocked silently in the background, they get surfaced to you, so you actually see that something was attempted and stopped.

The Honest Comparison

A site running Armor Lite already has baseline protection against bad bots and login/XML-RPC abuse a solid floor. Armor Pro goes further: it’s tuned rate limiting, custom rules built around your specific application, and visibility into what’s actually being attempted against your site each month, rather than protection running invisibly with no reporting at all.

The alternative noticing these signs only after they’ve become an actual incident is exactly the scenario that leads to an emergency call and an Armor SOS cutover instead. Catching the warning signs early is simply the cheaper, calmer version of the same problem.

Here’s a scenario that catches a lot of site owners off guard: you’ve got Cloudflare running, your WAF rules are active, Under Attack Mode is available if needed and yet an attacker is still hitting your server directly, seemingly walking straight past all of it. This isn’t a failure of the firewall. It’s almost always the same underlying issue: the origin IP is exposed, and the attacker has simply stopped knocking on the front door and gone around the back.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

What “Origin IP” Actually Means

Every website lives on a physical (or virtual) server with a real IP address the origin. When a service like Cloudflare sits in front of your site, visitors are supposed to reach that proxy first, and the proxy forwards clean, filtered traffic to your origin. Your firewall, WAF, and rate limiting all live at that proxy layer.

The problem: if someone already knows your origin’s real IP address, none of that filtering matters. They can send traffic attack traffic included directly to the server, completely bypassing the proxy, the WAF, and Under Attack Mode. It’s the equivalent of installing a reinforced front door while leaving a window wide open around the side of the house.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

How Origin IPs Get Exposed in the First Place

This happens more often than people expect, usually through:

• Old DNS records — if the site was hosted directly before a proxy was added, the original A record may still be cached or discoverable
• Subdomains that were never proxied — mail servers, staging sites, or API endpoints often point directly at the origin even when the main domain is protected
• Server misconfigurations — some server software reveals origin details in headers, error pages, or SSL certificate metadata
• Historical exposure — services like Shodan and Censys continuously scan and index IP addresses; if your server was ever exposed, even briefly, it may already be catalogued and searchable
• Third-party integrations — plugins, email services, or monitoring tools that connect directly to the origin rather than through the proxy

The unsettling part is that exposure doesn’t require an active attack to happen. It can sit there quietly for months, discoverable to anyone who looks, until someone decides to use it.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

Why This Matters Especially After an Incident

If a site has already been attacked once, and the response was simply “turn on Cloudflare,” there’s a real risk the origin IP was already seen by the attacker before protection went up during the attack itself, in server logs, in old configuration, or through simple reconnaissance beforehand.

In that situation, adding a proxy after the fact protects against new attackers finding the site through normal means, but it does nothing about the specific attacker who already has the real address written down. This is the gap that catches people who think the danger is over the moment the firewall goes up.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

Why Rotation Is the Actual Fix

Rotating the origin IP means assigning the server a new address and ensuring every path to it DNS records, subdomains, integrations — points only through the proxy going forward. Once that’s done, the old, exposed IP is dead weight; even if an attacker has it saved, it no longer leads anywhere.

This is meaningfully different from just “adding a firewall,” because it removes the bypass entirely rather than trying to filter traffic that’s using it. It’s not a step most standard hosting migrations include, because it’s not needed for a healthy, never-attacked site but after an incident, it changes IP rotation from optional to necessary.

Where This Fits in a Response Plan

This is exactly why Tremhost Armor SOS includes origin IP rotation as a standard part of emergency response, rather than treating “add Cloudflare” as the whole solution. A rushed cutover that skips this step can leave a site looking protected on paper while remaining fully reachable by the one attacker who already has the address that matters.

After Rotation: Keeping It That Way

Once an origin IP has been rotated and secured, the ongoing job is making sure nothing quietly re-exposes it again new subdomains added without going through the proxy, a plugin that connects directly to the server, or a misconfigured mail record. This is the kind of detail that’s easy to miss without regular review, which is part of what’s covered under Armor Pro and Armor Business‘s custom rule management and periodic configuration reviews.

Most people only learn how DNS and proxy protection work the day they desperately need it. So instead of another generic “what is Cloudflare” explainer, here’s an honest, step-by-step look at what actually happens when a site owner calls Tremhost mid-crisis and we run an emergency Armor SOS cutover start to finish.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

Why “Normal” Setup Timelines Don’t Work in an Emergency

A standard Cloudflare onboarding the kind done for Armor Lite is deliberately unhurried. DNS records get mapped carefully, SSL modes get tested, cache rules get tuned to the specific site type, and everything is verified before go-live. That process usually takes a few days, and for a healthy site, that pace is a feature, not a flaw it avoids downtime from misconfiguration.

None of that timeline is acceptable when a site is actively being attacked. Every hour of delay is an hour of lost sales, exposed customer data, or search rankings quietly draining away from downtime. Armor SOS exists because “we’ll get to it this week” isn’t an answer to “my site is down right now.”

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

Hour 0: Triage Call and Origin Assessment

The first thing we determine isn’t “what package do you want” it’s what’s actually happening. Is the origin server still reachable? Is traffic volume the problem, or is it unauthorized access? Is the domain’s current DNS provider going to cooperate with a fast change, or is propagation going to be a fight?

This assessment decides the order of operations. A DDoS-only situation and a compromised-origin situation get handled differently even though both start with the same emergency call.

https://tremhost.com/clientarea/store/tremhost-armor-powered-by-cloudflare

Hour 0–1: Emergency DNS Cutover

This is the step most people picture when they hear “cutover” but the value isn’t just “add Cloudflare,” it’s doing it fast and correctly under pressure, which is exactly where DIY attempts go wrong. Common mistakes we see from site owners trying this alone mid-attack:

• Leaving old A records active alongside the new proxy setup, giving attackers a second, unprotected path straight to the origin
• Missing subdomains (mail servers, staging environments, API endpoints) that stay exposed while the main domain looks “protected”
• SSL mode misconfigurations that either break the site entirely or leave a gap attackers can exploit

We map every record before touching anything, so the origin isn’t just partially shielded — it’s fully behind the proxy, including the parts of the domain people forget about.

Hour 1–2: Under Attack Mode + Emergency WAF Rules

Once traffic is routed through Cloudflare, Under Attack Mode is activated immediately this adds a browser verification challenge in front of every visitor, which filters out a large share of automated attack traffic before it ever reaches the server.

Alongside that, we deploy custom emergency WAF rules specific to what’s actually happening not generic templates. If it’s a login brute-force, we rate-limit and lock down the login endpoint specifically. If it’s an XML-RPC abuse pattern, that gets closed off directly. This is the difference between a firewall that’s “on” and a firewall that’s actually stopping this attack.

Hour 2–3: Origin IP Rotation (If Compromised)

If there’s reason to believe the attacker has the site’s real server IP from before protection was in place, or from a misconfiguration elsewhere — a proxy alone doesn’t fully solve the problem, because traffic can still be sent directly to that exposed IP, bypassing Cloudflare entirely.

In that case, we rotate the origin IP, which effectively cuts the attacker’s direct line to the server. Combined with the DNS cutover already in place, this closes the loop the only path to the site is now through the protected proxy.

Hour 3+: Stabilization Check and Monitoring

Once the immediate rules are live, we watch traffic and server load to confirm the site has actually stabilized not just theoretically protected, but genuinely handling load and rejecting malicious requests as expected. Adjustments get made in real time if something isn’t behaving as intended.

After Stabilization: The Post-Incident Summary

Once things are calm, the site owner gets a written summary of what happened and exactly what was changed — DNS records modified, rules added, IP changes made. This isn’t just documentation for its own sake; it matters for:

• Explaining to customers or stakeholders what happened, if disclosure is needed
• Compliance and audit trails, particularly for ecommerce or PCI-relevant sites
• Deciding what ongoing protection makes sense going forward

What Comes Next

Armor SOS is designed to stop the emergency it’s not meant to be the permanent state of a site’s security. Once stabilized, most site owners move to Armor Lite or Armor Pro, where the same protections (WAF, rate limiting, proxy, DDoS mitigation) run continuously, tuned and monitored, instead of reactively deployed under pressure.