SeQontrol.com

Static marketing site for the SeQontrol platform. Hand-written HTML/CSS/JS — no build step, no package manager, no external network requests at runtime (no CDN, no font host, no analytics). The three typefaces are self-hosted under assets/fonts/.

Open index.html in a browser, or serve the folder:

python -m http.server 8080

Layout

index.html          Home — pitch, products, platform, pricing preview, MSP, honesty section
platform.html       The shared platform layer + the trust/security answers
pricing.html        Every price, plus the per-product capability tabs and metering rules
for-msps.html       Provider model, commercials, land-and-expand motion
contact.html        Contact + a form that composes a mailto (no backend, nothing submitted)
limits.html         What the platform deliberately does not do
about.html  security.html  privacy.html  terms.html   Company and legal
exposure-report.html  spoofing-report.html  surface-report.html   The three free assessments
vs-cipp.html  vs-grc-platforms.html  vs-m365-governance.html  vs-secure-score.html   Comparisons
404.html            Not-found page (noindex, carries the same chrome)
products/
  index.html        Product overview + at-a-glance comparison table
  sharecare.html  securityportal.html  webscan.html  mailtrust.html    the four shipped products
  conditionalaccessportal.html  complianceportal.html                    coming soon
  postureportal.html  dredd.html                                         in development
  coming.html       A redirect stub. The four unreleased products shared this page behind
                    anchors until 2026-08-23; it was in the sitemap and half the site linked
                    to it, so it redirects rather than 404s.
guides/
  index.html  dmarc-without-breaking-mail.html  evidence-auditors-accept.html
  what-copilot-can-reach.html
css/styles.css      Single stylesheet
js/site.js          Mobile nav, current-page marker, footer year, audience doors, tabs, contact form
assets/             Logo extractions, on-dark variants, icons, OG card
  fonts/            Sora, Manrope and JetBrains Mono (latin + latin-ext WOFF2) with their OFL licences
  Screenshots/      Published crops + their lossless WebP twins. The raw captures live here too
                    and are gitignored — they still carry a real third-party domain.
favicon.ico         Multi-resolution icon at the root, where browsers look for it
.github/workflows/deploy.yml   Verify, then publish to GitHub Pages
CNAME, .nojekyll, robots.txt, sitemap.xml

Regenerating

Most of the site is generated. Editing generated HTML directly is the one way to lose work here: the next generator run overwrites it, silently and completely. If a change belongs to something in tools/, make it there.

Order matters — each step depends on the one above it:

python tools/build_legal.py       # pricing + trust pages; leaves <!--CAPS:key--> markers
python tools/build_guides.py      # the guides, from the same page chrome
python tools/build_licensing.py   # fills those markers with capability tabs and matrices
python tools/build_prices.py      # price blocks on the product pages, from tools/prices.py
python tools/build_nav.py         # nav, footer, product cards, skip links, contact address
python tools/build_seo.py         # titles, metadata, canonicals, JSON-LD, CSP, sitemap
python tools/build_images.py      # lossless WebP twins + <picture> wrappers
python tools/verify.py            # the gate CI runs on every push

tools/

verify.py           Pre-deploy checks — links, markup, a11y, SEO, editorial rules, shipped JS
_chrome.py          The page shell, split out of contact.html and shared by the generators
build_legal.py      Pricing and the legal/trust pages; owns CONTACT and the money figures
build_licensing.py  Per-product capability tabs and matrices, injected into pricing.html
build_guides.py     The guides section
prices.py           The list prices quoted OUTSIDE pricing.html, as data (writes nothing)
build_prices.py     Fills the <!--PRICE:key--> and <!--PRICE-TIERS:key--> blocks from prices.py
build_nav.py        Everything repeated on every page, derived from one PRODUCTS list
build_seo.py        Metadata, canonicals, JSON-LD, the CSP meta tag, sitemap.xml
build_images.py     PNG -> lossless WebP (69% smaller) and the <picture> markup
build_frameworks.py The compliance framework catalogue as DATA (7 families, 24
                    frameworks). Writes nothing; pricing quotes its count.
extract_logo.py     Re-keys the supplied logo JPEG into transparent PNGs
make_logo_variants.py  On-dark variants, sized copies, OG card
make_icons.py       favicon.ico and the PNG icon set
crop_screenshots.py  redact_screenshots.py   Raw capture -> publishable crop

Only build_images.py needs anything installed (pip install Pillow), and only when a screenshot changes — the WebP files are committed, so CI never runs it.

The three artwork scripts need Pillow too. extract_logo.py has to run first because the other two read what it produces; after that the order does not matter.

python tools/extract_logo.py        # supplied JPEG -> transparent symbol/wordmark/tagline
python tools/make_logo_variants.py  # on-dark variants, sized copies, OG card
python tools/make_icons.py          # favicon.ico and the icon set

Until 2026-08-31 the last two both wrote favicon-32.png, apple-touch-icon.png and icon-512.png from the same source symbol, recoloured differently — so whichever ran last decided what the site shipped, and the order was a contract nothing enforced. make_logo_variants.py no longer writes icons at all. The two scripts now have no output file in common.

make_icons.py kept the job because its treatment is the one the site links and the only one that answers for a light browser strip: it lifts the navy shield to pure white for contrast against chrome it does not control, puts the apple-touch icon on an opaque #0b0f17 tile because iOS composites transparency onto black and does not pad, and writes both favicon.ico and the navy favicon-32-light.png that sits behind prefers-color-scheme: light. A white shield disappears on a light strip, and the other script had no answer for that.

None of the three runs in CI, and none of them run at import: they rewrite tracked binaries, so they only act when invoked directly. extract_logo.py reads artwork that is deliberately not in this repo; point SEQONTROL_LOGO_SRC at it. Both preview images go to SEQONTROL_PREVIEW_DIR (default Z: mp) rather than into the site.

Hosting — GitHub Pages

The repository root is the site: no build step, so the whole checkout is published as-is. .github/workflows/deploy.yml runs tools/verify.py first and only deploys if it passes — pull requests are verified but never published.

One-time setup

The repository must be public unless you pay for GitHub. GitHub Pages on a private repository requires Pro, Team or Enterprise. On the free plan, enabling Pages on a private repo fails with HTTP 422: Your current plan does not support GitHub Pages for this repository, and the deploy job dies at configure-pages. Repository visibility and site visibility are separate things: a public repo means the source is readable, which for a hand-written marketing site is mostly the same content the site already serves — but read the "What goes public" note below before flipping it.

git init -b main
git add .
git commit -m "SeQontrol.com: initial site"
gh repo create seqontrol.com --public --source=. --remote=origin --push

The workflow sets enablement: true on configure-pages, so Pages is switched on automatically by the first successful run — no visit to Settings needed. To do it by hand instead: Settings → Pages → Build and deployment → Source: GitHub Actions.

What goes public

A public repository publishes this README alongside the site, and this file is candid by design: it records the ShareCare catalog mismatch, that scan cadence is sold but not yet enforced, and pointers to internal pricing material. None of that is secret, but none of it is written for customers either. Before making the repository public, either trim the "Things to change before it goes live" section and the internal cross-references, or keep the repo private and pay for Pages.

Custom domain

CNAME contains seqontrol.com, which is also what sitemap.xml, robots.txt and the og:image URL assume. Point the domain at GitHub:

Eight apex records — four A and four AAAA — plus one CNAME for www. Each value below is literal and complete; enter them exactly as written, one record per row.

Record	Name	Value
A	@	185.199.108.153
A	@	185.199.109.153
A	@	185.199.110.153
A	@	185.199.111.153
AAAA	@	2606:50c0:8000::153
AAAA	@	2606:50c0:8001::153
AAAA	@	2606:50c0:8002::153
AAAA	@	2606:50c0:8003::153
CNAME	www	<owner>.github.io

The AAAA values differ only in the fourth group (8000, 8001, 8002, 8003); :: is IPv6's own notation for a run of zero groups and is part of the address, not an abbreviation of mine.

Check these against GitHub's current documentation before you commit them. They are GitHub's published Pages addresses and have been stable for years, but hosting IPs are not a promise, and a stale A record is a site that silently stops resolving. Search GitHub Docs for "Managing a custom domain for your GitHub Pages site".

Then tick Enforce HTTPS in Settings → Pages once the certificate is issued (can take a few minutes to an hour). If your DNS provider supports ALIAS/ANAME at the apex, use that instead of the A and AAAA records — one record that follows GitHub's changes beats eight that do not.

Then verify the domain — see Security. Pointing a domain at GitHub without verifying it leaves it claimable by any GitHub user on the day this repository stops publishing.

Not using a custom domain? Delete CNAME, and update the absolute URLs in sitemap.xml, robots.txt and the og:image meta tag to your Pages URL. Every internal link in the site is relative (no leading / anywhere — tools/verify.py would flag one), so a project site served from https://<owner>.github.io/<repo>/ works without further changes. Those three absolute URLs are the only place the domain is hard-coded. Delete the DNS records above in the same change: a domain left pointing at GitHub with no repository claiming it is exactly the takeover described under Security.

Notes

• .nojekyll stops GitHub running the content through Jekyll. Nothing here starts with an underscore today, but the file costs nothing and removes a whole class of surprise.
• tools/ and .github/ are uploaded with the site. They are a few KB, are never executed by Pages, and keeping them in the artifact means the deployed tree matches the repository exactly.
• The site makes no external requests at runtime, so there is no CDN, font host or analytics endpoint to allow-list, and nothing to break when a third party changes. If that ever changes, read Third-party code first.
• Search engines. The site is verified in Google Search Console and Bing Webmaster Tools, with sitemap.xml submitted to both (2026-10-14). After every deploy to main, the indexnow job in deploy.yml sends the pages that changed to IndexNow (Bing, Yandex and others; Google reads the sitemap instead). 365386801392052bf24fb6390765394a.txt at the root is the IndexNow key file: it must stay there and contain only the key in tools/indexnow.py. Running the workflow by hand sends every page.

Security

The domain: verify it with GitHub, or anyone can take it over

The apex points at GitHub's shared Pages addresses and www is a CNAME to jeffwouters.github.io. Those records say "GitHub, serve this domain". They do not say which repository. While this repository publishes with CNAME set, it holds the claim. The claim ends the moment publishing stops: Pages switched off, the repository renamed, transferred or deleted, made private on the free plan (the HTTP 422 case under One-time setup), or the plan downgraded. The DNS records still point at GitHub, and nothing claims the domain. Unless the domain is verified on the owning account, any GitHub user can then add seqontrol.com to a repository of their own, and GitHub will issue them a valid certificate. On a security vendor's domain that is a phishing page with a padlock: a copy of exposure-report.html asking an MSP admin for Entra consent, or a /.well-known/security.txt that sends vulnerability reports to someone else.

Verification is an account setting plus one DNS record, so only the account owner can do it. State on 2026-09-15: verified. The owner added the domain on the JeffWouters account and the challenge TXT record in the Microsoft 365 zone; the Pages API reports protected_domain_state: verified. The steps below stay as the record of how, and for re-verifying if the repository ever moves to another account or organisation.

1. Verify the domain on the account (TXT record)

Verification belongs to the account that owns the repository (JeffWouters, a personal account), not to the repository.

1. GitHub → profile picture → Settings → Pages (under "Code, planning, and automation").

2. Add a domain → enter seqontrol.com (the apex, not www) → Add domain.

3. GitHub shows a TXT record. Create it in the zone exactly as shown. The zone is hosted by Microsoft 365 (ns1.bdm.microsoftonline.com).

   Record	Name	Value
   TXT	_github-pages-challenge-JeffWouters	the code GitHub shows (unique to the account, so it cannot be written here)

   Some DNS panels want the full name, _github-pages-challenge-JeffWouters.seqontrol.com. Others append the zone themselves. Enter the zone once, not twice.

4. Wait until the record resolves, then click Verify:

   dig +short TXT _github-pages-challenge-jeffwouters.seqontrol.com @1.1.1.1
   

   Resolve-DnsName -Type TXT _github-pages-challenge-jeffwouters.seqontrol.com -Server 1.1.1.1
   

5. Leave the TXT record in place permanently. It is the proof of ownership, not a one-time token. Do not tidy it away once the page says Verified.

Confirm it took. GitHub's Settings → Pages lists the domain as Verified, and the repository's Pages API should agree:

gh api repos/JeffWouters/seqontrol.com/pages --jq .protected_domain_state   # want: verified

Verification protects the domain and its immediate subdomains, so www.seqontrol.com is covered by the same record. Deeper names such as a.b.seqontrol.com are not. Verification is per account or organisation: if this repository ever moves to an organisation, verify the domain there as well.

2. Keep the CNAME

• The CNAME file stays in the repository, containing seqontrol.com. Every deploy re-asserts the claim from it. Deleting it releases the domain on the next publish while DNS still points at GitHub.
• The repository's Settings → Pages → Custom domain stays seqontrol.com, with Enforce HTTPS on.
• The DNS www record stays a CNAME to jeffwouters.github.io: this account's own Pages host, never another account's.

3. Remove stale DNS, and remove it first when Pages is going away

• Audit the zone for records that point at GitHub for a site nobody publishes. That means A/AAAA records to 185.199.108.153–185.199.111.153 or 2606:50c0:8000::153–2606:50c0:8003::153, the retired Pages addresses 192.30.252.153 and 192.30.252.154, and any CNAME to a *.github.io host. Delete every one that no repository on this account currently serves.
• Never add a wildcard. No *.seqontrol.com record may point at GitHub. GitHub's own documentation warns that a wildcard record is an immediate takeover risk even when the domain is verified. There is none today (a random subdomain returns NXDOMAIN), so keep it that way.
• Before any change that stops this site publishing, delete the four A records, the four AAAA records and the www CNAME. Only then make the change. That covers switching Pages off, making the repository private without a paid plan, renaming, transferring or deleting it, and downgrading the plan. Put the records back only once a site is publishing again. Keep the TXT record throughout.

4. Optional: CAA

A CAA record limits which certificate authorities may issue certificates for the domain. It is not a takeover fix, because GitHub would issue a hijacker's certificate from the same CA it uses for this site. It is defence in depth against mis-issuance by every other CA. GitHub Pages certificates come from Let's Encrypt:

Record	Name	Value
CAA	@	0 issue "letsencrypt.org"
CAA	@	0 issue "digicert.com"

The second line is required as soon as the app is live: app.seqontrol.com, api.seqontrol.com and the portal subdomains (*.app.seqontrol.com) run on Azure Static Web Apps and Container Apps, whose managed certificates come from DigiCert. Without it their next renewal fails.

CAA applies to every name below it too. Before adding it, list every other host in the zone that serves TLS on a seqontrol.com name, and add an issue line for each of their CAs, or that host's next renewal fails. If the DNS host does not offer the CAA record type, skip this step. It is not worth moving the zone for.

Third-party code

Nothing is loaded from another origin today, and the CSP written by build_seo.py (script-src 'self') enforces that in the browser. If that ever changes (the ANALYTICS hook in build_seo.py exists for exactly that), every script or stylesheet loaded by absolute URL must carry Subresource Integrity. tools/verify.py (check_subresource_integrity) fails the build when one does not:

<script defer src="https://cdn.example/[email protected]/lib.min.js"
        integrity="sha384-..." crossorigin="anonymous"></script>

• Pin a versioned URL. SRI on a URL whose content changes in place (/latest/, /js/script.js) breaks the day the vendor ships. If a vendor only serves a moving URL, self-host the file under js/ instead, and it stops being third-party.
• Hash the exact file you reviewed: curl -s <url> | openssl dgst -sha384 -binary | openssl base64 -A.
• crossorigin="anonymous" is required. Without it the browser cannot check a cross-origin file against its hash, and it blocks the file.
• Allow the host in the CSP in the same commit. script-src (or style-src) in build_seo.py still has to name it, or the browser refuses the file regardless of its hash.

Brand and theme

• The site speaks as SeQontrol only (since 2026-10-14). JeffOps, the registered entity behind it, is named only where the law needs a party: the privacy notice (the controller) and the terms (the other party). Nowhere else: no footer credit, no link to jeffops.com, no parent organisation in the structured data. The contact address is [email protected]. verify.py fails any other page that mentions JeffOps.

• Light page, navy chrome (since 2026-10-10). The body is a cool light grey with white cards; the header, the heroes, the closing call-to-action panel and the footer are navy. This replaced the dark-only theme, whose neutrals came from the platform shell. The palette is SeQontrol's own:

  Token	Light	Navy chrome	Role
  --bg	#EEEFF5	#151C4F	page / chrome background
  --bg-deep	#E4E5EE	#10163F	.band, footer
  --surface	#FFFFFF	#1E2660	cards, panels
  --text	#151C4F	#FFFFFF	body text (Deep Navy on light)
  --muted	#3D4466	#D2D4E6	secondary text
  --dim	#565C7C	#A9ADC8	captions, hints
  --brand	#6C4FDF		Qontrol Purple — fills and primary buttons
  --accent	#4B33B8	#C3B8F5	links, eyebrows, labels

  Two token sets, one vocabulary. :root holds the light values; .on-navy and everything that is always navy (.site-header, .hero, .phero, .cta > .wrap, .site-footer, .navy-panel) re-declares the same custom properties with navy values. Write a component against the tokens and it works on either ground with no second set of rules.

Logo assets

The supplied logo arrived flattened to JPEG, so the original alpha was gone and the transparency checkerboard (30px cells) was baked in as real pixels. tools/extract_logo.py re-keys it:

• Measuring the file settles the ambiguity — the interior of the magnifying glass alternates 241/252 down its centre, i.e. the checkerboard shows through it. The lens is a hole, not a white fill, and so are the letter counters. Keying is therefore colour-based (light + neutral = background); a flood fill from the border would have wrongly kept those areas opaque.
• Edge pixels are un-premultiplied — the true ink colour is recovered from its blend with the white background — so there is no pale halo on a dark page.

Asset	What it is
seqontrol-symbol.png	Faithful extraction of the cloud + shield + magnifier, original colours
seqontrol-wordmark.png	Faithful extraction of "SeQontrol"
seqontrol-tagline.png	Faithful extraction of "Secure. Compliant. Confident."
*-on-dark.png	Site variants — see below
seqontrol-symbol-on-dark-{64,128}.png, seqontrol-wordmark-on-dark-320.png, seqontrol-tagline-on-dark-320.png	Sized copies, so a 32px slot does not pull a 644px image
../favicon.ico	Multi-resolution icon (16→256) at the site root, where browsers look for it
favicon-32.png, apple-touch-icon.png, icon-512.png	The same treatment as PNG
og-card.png	1200×630 social card, lockup on --bg

Why the on-dark variants exist. The delivered artwork is drawn for a light page: the wordmark and the shield are navy #1a1b4b, which is all but invisible on --bg #0b0f17. The variants keep the purple exactly as supplied and lift only the navy to --text #e5e7eb, interpolating between the two brand colours so anti-aliasing survives. The site uses the on-dark variants everywhere; the faithful extractions are kept as the source of truth for print, light backgrounds and hand-off.

If you would rather the site carried the artwork unaltered, swap the -on-dark filenames back to the plain ones in the header/footer — the wordmark will be very hard to read.

The icons match the site lockup: white shield, purple cloud, ring, magnifier and check, on a transparent background. The delivered artwork paints the shield navy because it is drawn for a white page; the icons lift it to pure white the same way the header lockup does, and leave every purple pixel untouched (interpolating between the two brand colours, so the anti-aliased rim stays clean).

The catch is the mirror of the old one: a white shield disappears on a light tab strip. So the navy original is emitted as favicon-32-light.png and linked behind media="(prefers-color-scheme: light)". Browsers honouring that swap to it; everything else falls back to favicon.ico, which is the white-shield version. Do not "simplify" by deleting one of the two links — that is what the pair is for.

apple-touch-icon.png is opaque on a dark tile (#0b0f17): iOS ignores alpha and composites home-screen icons onto black, and a white shield needs a dark ground anyway. Regenerate everything with tools/make_icons.py.

Accessibility

Audited and fixed; re-check with tools/verify.py, which parses every page and fails on missing lang, multiple or missing h1, skipped heading levels, duplicate ids, images without alt, unlabelled form fields, missing landmarks, th without scope, unreachable scroll containers and vague link text. It currently reports clean across all 12 pages — keep it that way when editing.

What that involved, and why, so it does not get undone:

• Contrast. Every text token clears WCAG AA (4.5:1) against all four surfaces it can sit on; the lowest is --dim at 5.20:1 (light theme, on --bg-deep; see Brand and theme). In the dark theme --dim was #6b7490, which measured 3.71–4.22:1 and carried hints, captions and the footer line — all small text. It was lifted at the same hue to #7c87a3. White on --brand is 5.55:1 and on --brand-dark 4.87:1, which is why hover lifts only that far. ::placeholder is set explicitly because the browser default fails here.
• Heading order. No level is skipped anywhere. Callout and aside headings are h3, footer column headings are h2 (they follow the page's last section heading, so h4 would skip), and the hero's step panel has a visually hidden h2 so its steps can be h3. Callout headings are styled by container (.note h2, .note h3) rather than by element, so the level can follow document structure without changing how anything looks — do not restyle these by element.
• Landmarks. header / nav[aria-label="Main"] / main / footer on every page, plus aside where there is a complementary column.
• Tables. Column headers carry scope="col", matrix row labels are th scope="row", and group rows are th scope="colgroup". thead th and tbody th are styled separately so row headers do not inherit the uppercase column-header treatment.
• Scrollable regions. Every .table-scroll has tabindex="0" — without it a keyboard user cannot scroll a wide table at all. The generated matrices also carry role="group" and a label.
• Tabs implement the full pattern: roles, aria-selected, roving tabindex, arrow/Home/End keys, and panels that stay reachable. They degrade to stacked content without JavaScript.
• Ticks and dashes are aria-hidden glyphs paired with .sr-only "Included" / "Not included", so the matrices are not read as a grid of meaningless symbols.
• Motion is disabled under prefers-reduced-motion. Focus is never removed; the ring is --focus at 6.32:1.

Content rules baked into the copy

• Be exact about consent and onboarding. Each product that reads a tenant has its own Entra app and its own admin consent, scoped to that product's permissions — the rule verify.py enforces, citing the code (AppHost.cs, Connectors/Program.cs, Dredd's GraphDirectoryRefResolver). Adding a product is therefore a second consent, through the same onboarding flow — never a second integration project — and revoking one revokes exactly one. Never write that the admin "consents once", that adding a product "never asks for new permissions", or that products share "one connection": verify.py refuses those phrasings, and since 2026-10-10 it collapses whitespace first, so a claim wrapped across two source lines is caught too. The adjacent planes do not ride the Graph consent: Exchange admin needs a certificate and its own role, Power Platform a pre-registered service principal, Azure/Log Analytics a workspace and reader role, DNS its own OAuth2 flow per provider. Write-back is a separate consent round trip. platform.html carries the full step-by-step table; do not compress it back into "connect once". (Until 2026-10-10 this bullet described one Entra app for the whole platform, contradicting verify.py and every page; if the code has since moved to a single app, change the rule, this bullet and the pages together.)

• Security stands above compliance. The key principle, stated in the #principle section on the home page (the full argument sits in its "Why security comes first" disclosure), reinforced in the CompliancePortal scope area and on the platform trust list. The argument: a compliance control can be waived, which turns the report green without changing the estate — so the security finding is treated as the fact and compliance as an interpretation laid over it. A waived finding stays visible and scored, and its exception expires. Do not let later copy imply compliance is the goal or that a green report equals a secure estate.

• The three portals are grouped, with no bundle name. The group headline is the agreed phrase: "Three products. One platform. Zero compromise." — on products/index.html. The homepage heads its product section "One platform. Products you switch on and off.", above the three availability groups.

• CompliancePortal scope. Every mention says it covers the technical implementation of controls on the platforms SeQontrol supports — not a whole-company compliance programme, and not an audit opinion. The full carve-out (policies, HR process, physical security, vendor management, anything on an unsupported platform) is a prominent box near the top of its section on products/coming.html.