BlueHour Cyber is a focused demonstration from BlueHour Technology.
BlueHour Sites

BlueHour Technology is the corporate home. BlueHour60 is the primer on all sixty Micro Operating Models. Focused sites each demonstrate part of the Operating Model.

BlueHour Cyber · Cyber Defense Through Operating Architecture

When an attack gets in, what can safely keep operating?

The answer depends on what the compromised component can reach, which workflows depend on it, what remains trustworthy and who has authority to act. Explore how BlueHour connects those relationships to business consequences and response decisions.

Explore the Demonstration Request a BlueHour Discussion

Conceptual Operating Architecture Demonstration. Synthetic data and predefined rules. No connection to a live enterprise.

Day 1, 02:14 · the scenario you will work through

A supplier's service account is compromised. Through an integration service it can instruct an AI purchasing agent, and the purchasing workflow can approve payments. $1,840,000 of invoices are queued for the 06:00 payment batch. Payroll for 6,200 people runs at 10:00.

The argument in one minute

Five things the scenario shows.

  1. Unnecessary assets carry economic and defensive obligations.

    $811,000 a year and 51 credentials removed by retiring five unneeded assets.

    Capital Discipline

  2. A smaller estate can still be compromised.

    5 components a single compromised supplier account can still act on.

    What it can reach

  3. Containment choices have different business consequences.

    $1,840,000 released to an unverified account under the cheapest response, held under the recommended one.

    The three responses

  4. Dependencies, trust, economics and authority inform the response together.

    6 MOMs each test one part of the same decision, and no single one settles it.

    The six MOM findings

  5. Recovery requires evidence and accountable approval.

    7 recovery stages, each needing a passed check and a named approver.

    Evidence and authority

Every figure on this page comes from the same synthetic scenario the demonstration runs. Illustrative Enterprise Simulation

Before anything gets in · MOM-001 Capital Discipline

Every technology asset has a cost to own and a cost to defend.

MOM-001 challenges both.

TakeawayIn this scenario, controlled retirement reduces annual estate cost by $751,000 (after a $60,000 monitoring investment) and removes 51 credentials and three action paths, while preserving all four critical workflows. Illustrative Enterprise Simulation

  • Annual estate cost$14.13M → $13.38M
  • Credentials, keys and tokens107 → 56
  • Relationships that permit action10 → 7
  • Critical workflows4 → 4

Kept on purpose

Low use is not a reason to sell.

The backup vault is used 3% of the time and the emergency access account twice a year. Both are held because recovery depends on them. The supplier integration is held because purchasing needs it, and the review buys monitoring for it.

What it does not change

A smaller estate can still be compromised.

Capital Discipline is not a cybersecurity control. It removes some of what security must understand, monitor and defend. It does not remove cyber risk, as the next section shows.

Review the asset decisions Nine MOM-001 verdicts: cost to own, access held and the reason
MOM-001 verdicts on selected assets
AssetVerdictCost to own a yearAccess it heldWhy
Legacy CRM (acquired)SELL Consolidate$410,000 removed9 credentials. Syncs customer records nightlyDuplicates the current customer service platform. Two remaining reports can run there.
Dormant contractor accounts (group of 38)SELL Deprovision$46,000 removed38 enabled accounts that can still sign in; residual ERP roles from old projectsNo sign-in for over 180 days. Contracts ended. Accounts still hold sign-in and ERP roles.
Legacy file transfer linkSELL Retire$85,000 removed2 credentials. Drops files into accounts payableSupplier offboarded two years ago. The link can still write into accounts payable.
Abandoned AI pilotSELL Decommission$120,000 removed1 credential. API key reads the data warehousePilot ended. Its API key still reads the data warehouse and its cloud resources still bill.
Former analytics vendor linkSELL Terminate connection$150,000 removed1 credential. Weekly export of customer dataReplaced by an internal capability. Still exports customer data weekly.
Immutable backup vaultHOLD Retain$450,000 kept2 credentials. Takes immutable hourly backups; takes immutable daily backupsUtilisation is 3%, which is the point. A backup vault is judged by the day it is needed, not by daily use.
Emergency access accountHOLD Retain$20,000 kept1 credential. Emergency administration if normal admin failsUsed twice a year. Without it, a failed admin path can lock the enterprise out of its own identity provider.
Supplier integration serviceHOLD Retain$520,000 kept4 credentials. Passes supplier requests to the agent for action; posts supplier invoices into accounts payableEssential to purchasing. Earns its return. Supplier access should stay scoped to what each supplier needs.
Monitoring for the supplier integrationBUY Extend coverage+$60,000Adds monitoring of supplier API activityThe retained supplier integration was not covered by security monitoring. Extend monitoring to it.
Compare the estate before and after Seven measures, Enterprise A and Enterprise B
Enterprise A compared with Enterprise B in the synthetic scenario
MeasureBefore (Enterprise A)After (Enterprise B)What it means
Components drawn1813One node before groups 38 dormant accounts.
Relationships2318Six removed with retired assets. One monitoring relationship added by the BUY.
Relationships that permit action107Fewer paths that can change records, issue instructions or approve.
Credentials, keys and tokens10756Fewer identities that could be misused.
Defensive obligations5640Patching, monitoring and access reviews no longer needed.
Annual estate cost$14.13M$13.38MPer year, including the $60,000 BUY. One-time decommissioning of $140,000 shown separately.
Critical workflows retained44Purchasing, customer service, payroll, order intake and billing.
See how controlled decommissioning works Seven steps before an asset leaves the attack surface

What the enterprise no longer needs, the enterprise no longer has to fund, integrate, govern, maintain, patch, monitor or defend. That holds only once disposition is complete.

  1. Check business dependenciesWho and what still relies on it.
  2. Respect data retentionArchive or delete under the retention rule.
  3. Honour contractsNotice, term and data return.
  4. Approve accountablyA named owner signs the disposition.
  5. Revoke credentials and tokensEvery identity and key it held.
  6. Remove integrationsAnd close the access paths.
  7. Confirm what remains worksDependencies tested after removal.

An abandoned asset that still runs or still holds access has not left the attack surface.

Compromised access

Something still got in. Now what?

TakeawayOne compromised supplier account can drive five components through relationships that permit action, ending at payment approval. Four more exchange data with them. None of this is confirmed compromise yet. Illustrative Enterprise Simulation

  1. Supplier service accountSuspected
  2. can change
  3. Integration serviceOperationally exposed
  4. instructs
  5. Purchasing agent (AI)Operationally exposed
  6. instructs
  7. Purchasing workflowOperationally exposed
  8. approves for
  9. Payments hubOperationally exposed
  • Operationally exposedReachable through a relationship that permits action, so compromise can propagate into what it does.
  • Possible data exposureExchanges data with an exposed component. Its information may have been read, exported or altered. Trust is unknown until verified.
  • Confirmed compromiseEstablished by evidence, not by connectivity.
  • UnaffectedIndependence established by the scenario's evidence.

Exposure is not compromise. Relationships that permit action govern how compromise can propagate through operations in this scenario, but they are not the only form of cyber exposure. Data-only access can still expose confidential information, allow exfiltration, or let compromised information shape later decisions, so the demonstration marks those relationships too and never treats them as safe.

See the defense sequence, step by step Reduce, detect, verify, contain, preserve, reconfigure, recover
  1. ReduceRetire unnecessary assets and relationships before anything goes wrong.MOM-001
  2. DetectExisting security technology supplies the signal.Your security stack
  3. VerifyWeigh evidence about identities, instructions, data and operating state, including what data may have been exposed.MOM-405
  4. ContainLimit the affected relationships under the appropriate authority.MOM-305 · MOM-505
  5. PreserveKeep operating what the scenario's safety conditions support.MOM-305
  6. ReconfigureChange selected workflows, including a constrained manual alternative.MOM-304 · MOM-305
  7. RecoverRestore in stages after evidence and dependency checks, with approval.MOM-305 · MOM-405 · MOM-505

These activities overlap. Urgent, preauthorized containment can come before verification is complete.

Interactive demonstration

Follow the decision from alert to recovery.

Conceptual Operating Architecture Demonstration

  • Your roleYou act for the leadership team of a synthetic enterprise: you approve the asset decisions, choose the response and sign off recovery stages as the named owners.
  • The decision aheadAt step 7, choose one of three responses to the compromised supplier account. Each stops, preserves and costs something different.
  • How to moveNext Step advances. Back undoes your last action and Reset starts over. Nothing plays unless you press Start. Every click is a simulated decision on synthetic data; nothing touches a real system.

The scenario in brief

  1. Accumulated estate. Enterprise A: 18 components and 23 relationships, including a redundant CRM, 38 dormant contractor accounts, a legacy file transfer link, an abandoned AI pilot and a former vendor's data connection.
  2. Disposition review. MOM-001 proposes five SELL dispositions, holds the backup vault, emergency access account and supplier integration, and buys monitoring coverage for the integration. The CIO and CFO approve.
  3. Rationalized estate. Enterprise B: 13 components and 18 relationships. All four critical workflows retained.
  4. Alert received. Security monitoring flags the supplier service account at 02:14.
  5. Exposure assessed. Five components are operationally exposed along relationships that permit action. Four exchange data with them, so their information may be exposed and their trust state is unknown. Three are unaffected.
  6. Trust review. The bank-detail instruction stays untrusted. Payroll and customer service independence is verified. The purchasing agent's configuration history is unavailable.
  7. Response alternatives. Restrict the identity and integration; suspend automated purchasing with a manual fallback (recommended by the stated rule); or broadly halt operations.
  8. Authorized containment. Preauthorized actions by the Incident Commander. The COO approves the manual fallback; the CFO holds $1,840,000 of queued invoices.
  9. Degraded operation. Purchasing runs manually at 35% throughput. Payroll and customer service continue. Independent confirmation at 07:40 confirms the compromise.
  10. Recovery checks. Seven staged checks with hold points and approvals. A compromised identity cannot reinstate itself.
  11. Recovered operation. Capability restored in stages. Investigation and corrective work continue.

The interactive version needs JavaScript. The architecture explanation and the discussion form below work without it.

The response decision · six MOMs

Three responses, one recommendation.

TakeawayThe scenario recommends suspending automated purchasing with a manual fallback. It blocks the unverified payment path while preserving payroll, customer service and order intake. The cost is slower purchasing: manual at 35% throughput for about 53 hours. Illustrative Enterprise Simulation

Restrict the suspect identity and integration

Stops
Trading with supplier VND-17. Remittance changes are frozen.
Continues
Payroll, customer service, order intake and purchasing (still operationally exposed).
Exposed or uncertain
Operationally exposed: purchasing workflow, ERP and payments hub. Trust unknown: purchasing agent and data warehouse.
Principal cost
$1,840,000 released to an unverified account at 06:00; recovery uncertain.
Who authorizes
Incident Commander (preauthorized).

Suspend automated purchasing with a manual fallback

Recommended by the scenario rule

Stops
The purchasing agent, automatic payment approval and the three queued invoices.
Continues
Payroll, customer service, order intake and purchasing manually, at 35% throughput.
Exposed or uncertain
Trust unknown: data warehouse and ERP.
Principal cost
$60,950 of manual fallback effort over about 53 hours; invoices held.
Who authorizes
Incident Commander (preauthorized), COO and CFO.

Broadly halt relevant operations

Stops
The integration service, purchasing, the ERP and the payments hub, and with them order intake and payroll.
Continues
Customer service with reduced function.
Exposed or uncertain
Trust unknown: data warehouse.
Principal cost
$9,864,000 of order intake delayed over about 36 hours; payroll about 29 hours late.
Who authorizes
Incident Commander (preauthorized), Executive escalation and CFO.

Why the scenario recommends suspending automated purchasing with a manual fallback

It is the least disruptive option that leaves nothing suspect or unverified able to approve a payment. It relies on verified evidence that payroll and customer service are independent, and it accepts slower purchasing as the price.

The rule: Recommend the alternative with the least operating interruption that leaves no action-permitting path from a suspect, confirmed or unverified component to a consequential payment.

What could change the answer

  • If the purchasing agent's configuration history had been available and clean, restricting only the supplier identity and integration could have kept automated purchasing running.
  • If payroll and customer service independence could not be verified, a broad halt could be justified despite its cost to orders and payroll.
Compare the six MOM findings Each MOM tests one question against all three responses
The same response alternatives, assessed by each MOM (scenario rules, synthetic data)
MOM and the question it answersRestrict the suspect identity and integrationSuspend automated purchasing with a manual fallback RecommendedBroadly halt relevant operations
MOM-304 Complexity Ceiling ManagementDoes an action path still reach payments?UnfavorableYes. The purchasing agent stays active and can still drive automatic payment approval.FavorableNo. Nothing suspect or unverified can act on the payments hub.FavorableNo. Nothing suspect or unverified can act on the payments hub.
MOM-405 Truth PreservationWhat evidence does it rely on?UnfavorableRelies on the purchasing agent behaving as configured. The evidence that could show that (its configuration history) is unavailable.FavorableRelies only on verified evidence: payroll and customer service independence. Nothing unverified is left able to approve a payment.MixedRelies on no independence evidence. It also sets aside the verified evidence that payroll and customer service could continue.
MOM-305 Operating RiskWhat stops, and what keeps operating?MixedMinimal. Only VND-17 trading stops. Purchasing keeps operating while operationally exposed.MixedPurchasing degraded to manual at 35% throughput until recovery. Payroll, customer service and order intake continue.UnfavorableOrder intake and purchasing halted for about 36 hours, then purchasing runs manually. Payroll release delayed about 29 hours. Customer service cannot see billing status while the ERP is halted.
MOM-001 Capital DisciplineWhat does it cost?UnfavorableNo continuity cost; $1,840,000 of invoices released to an unverified account.Favorable$60,950 manual fallback; $1,840,000 of invoices held.Mixed$9,864,000 of order intake delayed; $19,550 manual fallback; $1,840,000 of invoices held.
MOM-505 Governance & AccountabilityWho must approve it?FavorableIncident Commander (preauthorized).FavorableIncident Commander (preauthorized), COO, CFO.MixedIncident Commander (preauthorized), Executive escalation, CFO.
MOM-508 Board DecisioningWhich impact limits does it cross?FavorableNone crossed. Executive committee and Board briefed on consequences.FavorableNone crossed. Executive committee and Board briefed on consequences.Mixed3 crossed: more than two critical workflows halted; payroll delayed; projected interruption of order intake longer than 4 hours. Executive committee engaged, Board informed.
Scenario recommendationRecommend the alternative with the least operating interruption that leaves no action-permitting path from a suspect, confirmed or unverified component to a consequential payment. Result: Suspend automated purchasing with a manual fallback.

Flags compare the alternatives on each question under the scenario rules. They are not scores and they are not added up. These six are existing BlueHour60 MOMs that an enterprise activates within its Operating Model, not a separate cyber product.

What each MOM is designed to do, and its limits Purpose and capability boundary for MOM-001, 304, 305, 405, 505 and 508

MOM-001

Capital Discipline

Purpose
Designed to continuously challenge technology investment through BUY, HOLD and SELL against return on invested capital, including what each asset costs to defend.
Capability boundary
Not a security control. It reduces some of what security must understand and defend. It does not eliminate cyber risk.
See it at step 2 →

MOM-304

Complexity Ceiling Management

Purpose
Designed to make relationships and concentrations of complexity visible, and to distinguish dependency, data access and relationships that permit action.
Capability boundary
The demonstration applies stated rules to a synthetic graph. The architecture is designed to support dependency analysis on enterprise data through validated integrations. It is not a measure of exploitability.
See it at step 5 →

MOM-305

Operating Risk

Purpose
Designed for controlled intervention: stop what must be stopped, preserve what can safely continue, and make the consequences of each choice explicit. The kill switch is one intervention within it.
Capability boundary
Actions on this site are simulated. Real enforcement would act through existing security and IT controls under validated integrations and enterprise policy.
See it at step 7 →

MOM-405

Truth Preservation

Purpose
Intended to help the enterprise determine which information, identities, instructions and operating states can be trusted, from evidence with a known source and time.
Capability boundary
Evidence on this site is simulated. The demonstration does not verify any real identity, instruction or record, and implements no cryptographic or identity verification. In an enterprise, trust decisions would depend on validated evidence sources, integrations and policy.
See it at step 6 →

MOM-505

Governance & Accountability

Purpose
Designed to make authority explicit: who can approve, what is preauthorized, what escalates, who can stop the system and who owns the outcome.
Capability boundary
Role assignments are illustrative, not universal corporate rules. Clicking a control records a simulated decision only.
See it at step 8 →

MOM-508

Board Decisioning

Purpose
Designed to present enterprise consequences and alternatives to executives and the Board.
Capability boundary
An illustrative exposure view. Not a formal valuation or a validated financial risk model.
See it at step 9 →

Evidence and authority · MOM-405 · MOM-505

Authority must survive the attack.

TakeawayContainment starts at 03:05 under preauthorized authority, before the compromise is confirmed at 07:40. The COO and CFO own the workaround and the payment hold, and the compromised account cannot approve its own reinstatement. Illustrative Enterprise Simulation

Accountability in the Loop

People cannot approve every automated action, so they set the architecture of authority instead: what may run on its own, within which boundaries, and what escalates to whom. Humans must be the loop: they own the boundaries, the exceptions and the outcome. When the normal identity channel is suspect, authority needs an independent path, which is why the compromised account's attempt to approve its own reinstatement is refused.

Truth becomes an operating requirement.

At 02:21 the supplier account asks for a bank-detail change and the release of $1,840,000. It looks routine and cites a contract amendment that does not exist. A plausible instruction cannot authorise a payment or a recovery step, so each piece of evidence keeps its status, source and time.

  • Verified

    The scenario's defined checks passed. Example: the simulated payments hub configuration shows payroll uses a separate dual-control release.

  • Unverified

    An assertion that has not passed checks. Example: the instruction to change the supplier's bank account.

  • Conflicting

    Evidence disagrees. Example: the instruction cites a contract amendment the contract repository does not hold.

  • Unavailable

    The evidence does not exist or cannot be reached yet. Example: the purchasing agent's configuration history. It stays unavailable, and that changes the decision at step 7.

Review who authorizes each decision Six decisions, their owners and the basis for each
Illustrative authority in the scenario
DecisionOwnerBasis
Predefined containment: revoke the suspect session, restrict the integration, suspend automationIncident Commander (delegated by the CISO)Preauthorized
Material operating workaround: manual purchasingCOOApproval required
Consequential payment exposure: hold or release invoicesCFO or authorised finance leaderApproval required
Broad halt, or any defined impact limit crossedExecutive escalationEscalation
Supplier credential reinstatementProcurement Director, through an independent channelNever the suspect identity
Strategic consequences and escalationBoardInformed; not running technical actions

Illustrative assignments for this scenario, not universal corporate rules.

"Verified" means only that the scenario's predefined checks passed. The browser demonstration does not establish trust in any live system or enforce any control. In an enterprise, Truth Preservation would depend on validated evidence sources, integrations and policy.

Business consequences · MOM-508 Board Decisioning

Enterprise Value at Cyber Risk

Risk is the enemy of money.

TakeawayEach response moves the cost somewhere different: $1,840,000 released under targeted restriction, $60,950 of manual effort under suspension, $9,864,000 of delayed orders and a 29-hour payroll delay under a broad halt. The figures stay separate because they overlap. Illustrative Enterprise Simulation

In the synthetic scenario, suspending automated purchasing with a manual fallback costs about $61,000 in fallback effort over 53 hours and holds $1,840,000 of queued invoices. Restricting only the identity and integration avoids that cost but lets the invoices release to an unverified account. A broad halt delays about $9.9 million of order intake and payroll for 6,200 employees. Figures are scenario estimates with stated assumptions. The interactive comparison needs JavaScript.

Why more automation needs more architecture Cyber Operating Leverage, as a conceptual comparison

The purchasing agent saves effort every day, and on the night of the incident it was the component nobody could vouch for. Cyber Operating Leverage is the intended operating relationship: adding intelligence and automation without letting unnecessary complexity, defensive cost and propagation exposure grow alongside them. More intelligence requires more architecture, not less.

Conceptual comparison. There is no index, ROI percentage or measured relationship here between fewer graph edges and lower loss probability.

Conceptual comparison of operating burden Two conceptual curves. Without Operating Architecture, operating burden rises steeply as intelligence, connectivity and automation increase. With Capital Discipline, architectural visibility and accountable response, burden rises much more slowly. No values are implied. More intelligence, connectivity and automation → Operating burden → Relationships and authority poorly understood With Capital Discipline, visibility and accountable response
Conceptual only. No scale or values are implied.

Existing security architecture

Keep the Cybersecurity Stack

Make it part of the Operating Model.

Security leaders already map critical dependencies, plan for continuity and run incident governance. Their platforms supply the detection, containment and evidence this scenario depends on: the alert at 02:14, the session revocation, the integration block and the logs behind every evidence item.

BlueHour's intended contribution is narrower and specific: connecting assets, permissions, workflows, evidence, authority and economics across the enterprise in one model, so that accountable leaders in security, operations and finance can evaluate consequences and alternatives on the same facts.

Security categories that supply signals and enforce controls

  • Detection and response
  • Identity and access
  • Endpoint
  • Network
  • Cloud
  • Application
  • Data security
  • Vulnerability management
  • Observability

Operating context (not cybersecurity tools)

  • Business systems: ERP, CRM, HR and payroll, payments
  • IT service management

Interfaces shown in the demonstration are illustrative. No vendor integrations, certifications or partnerships are claimed. A generic adapter in a demonstration is not a completed enterprise connector.

Architecture

The agent is not the system. The security product is not the system. The enterprise is the system.

The scenario turned on relationships, not on any single component: a supplier identity that could change an integration, an agent that could instruct a workflow, a workflow that could approve payments, and data flowing to systems that payroll and customer service depend on.

In the intended architecture, signals from specialized technologies are related to the enterprise's dependencies, evidence, authority and economics. Relationships that permit action govern how compromise can propagate through operations; data-only relationships carry a different exposure, because information can be read, exported or altered and then shape later decisions. Recommendations go to the people who hold authority, authorized actions return through the relevant controls, and evidence and action records feed back. Human accountability governs the whole loop, not a final sign-off after automation has acted.

BlueHour Operating Architecture for cyber defense Specialized security technologies send signals into BlueHour Operating Architecture, which holds the relationship model, evidence, authority rules and economics through six cooperating MOMs. It sends recommendations and alternatives to the people who hold authority. Authorized actions return through the relevant security and IT controls to the enterprise. Evidence and action records flow back into the architecture. A human accountability band spans the whole architecture, governing recommendations, permissions, escalation and recovery. Human accountability Sets authority and boundaries · owns exceptions, escalation and recovery · owns the outcome Specialized technologies Detection and response Identity and access Endpoint · Network · Cloud Application · Data security Vulnerability · Observability Context: business systems, ITSM BlueHour Operating Architecture Relationship model · Evidence · Authority rules · Economics MOM-001Capital Discipline MOM-304Complexity Ceiling MOM-305Operating Risk MOM-405Truth Preservation MOM-505Accountability MOM-508Board Decisioning Recommends alternatives · records decisions Enforcement depends on validated integrations and policy The enterprise Workflows and services Identities and permissions Data and integrations Agents and models Vendors and people signals recommendations, alternatives authority, decisions context authorized actions enforced through the relevant controls evidence and action records (feedback) results
Signals enter; recommendations go to the people who hold authority; authorized actions return through existing controls; evidence and action records feed back. Human accountability spans the whole architecture.
Review decision owners and enforcement boundaries Continue, restrict, verify, isolate, reconfigure, stop, recover
Actions, decision owners and enforcement boundaries (illustrative)
ActionDecision ownerEnforcement boundary
ContinueWorkflow owner, within conditions established by evidenceBusiness operations
RestrictIncident Commander, within preauthorized scopeIdentity, integration and access controls
VerifySecurity operations and data ownersEvidence sources and records
IsolateIncident Commander; wider isolation escalates to the CIONetwork, endpoint and cloud controls
ReconfigureCOO for material workflow changesWorkflow and integration configuration
StopIncident Commander for predefined scope; executive escalation for a broad haltEnterprise operations
RecoverNamed stage owners: Incident Commander, Procurement Director, CFO, COOStaged restoration through existing controls

Actual enforcement would depend on validated integrations and enterprise policies. In this demonstration every action is simulated.

Where this site fits

BlueHourTechnology.com is the corporate home of BlueHour Technology, the Enterprise Operating Model company. BlueHour60.com is the primer on all sixty Micro Operating Models. Focused sites such as BlueHourBusiness.com and BlueHourRisk.com each demonstrate part of the Operating Model. BlueHourCyber.com is a focused demonstration of cyber defense through Operating Architecture.

Which operations could your enterprise safely preserve during a compromise?

Discuss a critical workflow with BlueHour and explore the dependencies, authority and evidence a controlled response would require.

Request a BlueHour Discussion

Tell us who you are and which workflow you have in mind. We will reply by email to arrange a conversation.

This form is for a business discussion. It is not an emergency incident-response channel. If you are dealing with an active incident, contact your incident-response team or provider. Please do not include sensitive incident details here.

We use what you submit only to reply to you. See how we handle form submissions. You can also write to info@bluehourtechnology.com.

A short description. Please leave out sensitive incident details. Up to 800 characters.