Security
How SGEN keeps your site, your team, and your data under your control
Security in SGEN is the set of controls that decide who can sign in, what they can change, what gets blocked at the door, and what gets recorded after the fact. Every control is a real surface in the admin — not a marketing claim. This page is the entry point: what each control does, when to reach for it, and where the deeper docs live.
The shape of SGEN security is operator-first. The platform ships the controls a small team needs to run a site safely without bolting on extra software, and surfaces every meaningful action in the Activity Log so that the team can answer "who did what, when" later.
What is this for?
Use this page when you need to understand the security surface of your SGEN site at a glance — the access controls, the visitor-side blocks, and the auditability that ship in the box. Read it before opening Users, Blacklist, or any per-area security setting, so you know which control belongs to which job.
The five pillars on this page are: user accounts and roles, session control, visitor blocking via the Blacklist, action recording via the Activity Log, and authoring confidentiality — what you should and should not paste into a public surface from the admin.
Good use cases
- Onboarding a new team member and deciding which role they should hold.
- Removing a contractor's access on the day their engagement ends.
- Blocking a hostile IP that is hammering the public site.
- Reviewing what changed on the site after an unexpected layout shift.
- Handing a compliance reviewer a list of who has admin rights today.
- Recovering an account after a teammate forgets their password.
What NOT to use this for
- Treating SGEN as a substitute for device-level security on a teammate's laptop. If their device is compromised, their session is too.
- Using the Blacklist as a firewall for sustained DDoS traffic. The Blacklist blocks rules you add at the application layer; it is not a substitute for upstream network protection.
- Storing secrets (API keys, passwords) in user-facing fields like page content, post body, or popup copy. Those fields are visible to anyone who can read the page.
How this connects to other features
- Users — every account, role, and per-user permission lives here. Security starts with who has an account.
- Blacklist — visitor-level blocks evaluated on every public and admin request before the page renders.
- UX — interaction quality and consent surfaces (Tracking Consent) sit alongside security as the visitor-trust layer.
- Updates & Stability — platform-side update discipline removes the plugin-update vector that hits stacks built on third-party plugin chains.
Before you start
You need an admin account on the site. The role that controls security settings is Site Owner (the install owner) and Administrator. Editor and Customer roles cannot reach the security surfaces described here.
If you are reading this on a fresh install, log in once with the Site Owner account, open Users, and confirm the account list shows only the people who should have access. Everything below assumes you can see and change the Users list.
Where to find it
Security is not a single page in the SGEN admin — it is a set of surfaces under Users, Blacklist, and the Activity Log. The shortcut paths are:
- Users:
/sg-admin/users/ - Blacklist:
/sg-admin/blacklist/ - Activity Log: surfaced inside individual record views (post revisions, site backups, key admin events).
Steps
1. Audit who has admin access today
Open Users. Click the Administrator role pill at the top of the list. The count next to the pill tells you exactly how many admin-level accounts exist. Read the list. If a name on the list should not have admin rights, click Edit on that row and downgrade the role to Editor or Customer.
2. Remove access for someone who has left
On the user's row, hover to surface the inline actions. Click Trash. The account moves to the Trash tab and stops being able to sign in immediately. If the departure is permanent, open the Trash tab and use Delete Permanently to remove the row entirely. Trashed accounts can be restored from the Trash tab if you change your mind within the same session.
3. Block a hostile visitor by IP or CIDR range
Open Blacklist. In the left card, type the IP address or CIDR range (for example 203.0.113.45 or 203.0.113.0/24) into the Entry field. Add a short Reason in the textarea so a future teammate knows why the rule exists. Click Blacklist item. The next request from that IP returns blocked instead of the page.
4. Confirm the rule is firing
Back on the Blacklist list, find the rule you added. The Hits column counts how many times the rule has matched a visitor since it was created. The Last Matched column shows the most recent match timestamp. If a rule has zero hits over a week, it may be dead — review whether the threat is still active before keeping the rule.
The Blacklist also offers a Test IP tool in the right-card toolbar. Type any IP into the Test IP field and click Test. The tool returns whether the IP would be blocked under the current rule set, which lets you verify a CIDR rule covers the addresses you intended without waiting for a real visitor to hit the rule.
5. Review what changed on the site
Open the record you want to review (a page, a post, a settings panel). The record's revision history shows each save with the user who made it and the timestamp. Pair this with the Activity Log entries for site-wide events (theme activations, user role changes, bulk actions) to reconstruct a change window.
6. Hand off a security review
When a compliance reviewer asks "who has admin rights and when did each account last change," export the Users list (filtered to Administrator) and the Activity Log entries for the period. Both are surfaces a Site Owner can reach without engineering involvement.
What success looks like
A clean security posture on an SGEN site reads like this:
- Every account in the Users list belongs to a person who is currently working on the site.
- The Administrator role count matches the number of people who need admin rights — usually one or two for a small team.
- The Blacklist contains rules that have hit counts above zero in the last 30 days, or rules tied to a documented incident.
- Every settings change on the site has a name and timestamp attached to it via the revision history or the Activity Log.
If your site looks like this, the day-to-day security posture is healthy. The audits you run are spot checks, not investigations.
What to do if it does not work
Symptom: A teammate cannot sign in.
Open Users, find their row, and check the role and the status. If the account is in Trash, restore it. If the role is wrong, edit and reset. If the password is the issue, send the teammate the reset flow from the sign-in page — the admin does not see passwords.
Symptom: A blocked visitor still reaches the site.
Confirm the Blacklist rule covers the right IP. The Blacklist matches the literal IP or CIDR range you entered — a rule for 203.0.113.45 will not block 203.0.113.46. If the visitor is rotating IPs, narrow the block to a CIDR range and watch the Hits column for the next few hours.
Symptom: A rule shows zero hits but you know the visitor is hitting the site.
The Blacklist evaluates entries on every public and admin request. If hits are zero, the visitor is reaching a different IP than the one in the rule, or the request is being served from a cache that did not reach the application layer. Check both before assuming the rule is broken.
Symptom: A change happened on the site and you cannot find who made it.
Most surfaces record the last-modified user and timestamp on the record itself. For settings-level changes that span many records, check the Activity Log surface for the relevant area. If the change is not recorded anywhere, treat that as a finding — file it, then ask in your team what happened.
Symptom: An account you trashed is showing up in the role count.
The role pill counts accounts grouped by their role; trashed accounts move to the Trash tab and out of the role-pill counts. Refresh the page. If the count still looks wrong, the role was changed before the trash, and the count is reading the new role.
Examples
Example 1: Onboarding a new editor.
A new content editor joins the team. The Site Owner opens Users, clicks Add New, fills in name + email + role = Editor, and saves. The new editor receives a sign-in invitation. Their account appears under the Editor role pill. They can edit and publish content but cannot reach Users, Blacklist, or other security-side surfaces.
Example 2: Offboarding a contractor.
A contractor finishes their engagement on Friday. The Site Owner opens Users, finds the contractor's row, clicks Trash, then opens the Trash tab and clicks Delete Permanently. The account is gone. The next time the Activity Log is reviewed, the trash and the permanent-delete actions appear with the Site Owner's name as the actor.
Example 3: Blocking a scraper that ignored robots.txt.
The site owner notices a rapid burst of requests from a single IP range hitting /blog/* faster than any human reader. They open Blacklist, add the CIDR range with a short Reason ("scraper ignoring robots, 2026-04-29"), and save. Within an hour, the Hits column on that rule reads above zero. The scraper is blocked at the application layer before the page renders.
How roles map to capability
SGEN ships four roles out of the box, ordered from most to least access:
- Site Owner. The install owner. Cannot be deleted from the Users list. Has every capability the platform exposes, including switching to other accounts via the Switch To inline action.
- Administrator. Full admin access across content, settings, users, and security surfaces. The role you give a co-owner or technical lead.
- Editor. Can create, edit, and publish content. Cannot reach Users, Blacklist, Site Settings, or any structural surface. The role for a content team member.
- Customer. The role assigned to ecommerce customers when they create an account during checkout. Has no admin reach. Used to scope per-customer ecommerce surfaces (orders, addresses, account page).
A user can only have one role at a time. If you need a teammate to act as both an Editor and a contributor on a specific area, use the Editor role and rely on per-area permission scoping where it exists.
Session control
A signed-in admin session lives for the duration of the browser session unless the admin signs out. Closing the browser ends the session for that browser; the cookie does not survive a fresh launch.
There are three signed-in surfaces to know about:
- Sign in. The visible flow at
/sg-admin/. Posts the email and password to the auth gate. - Sign out. Available from the top-right user menu on every admin page. Ends the session immediately.
- Switch To. A Site Owner-only inline action on other users' rows that lets the Site Owner load the admin as that user without knowing their password. Used for support and debugging. Every Switch To action is recorded in the Activity Log.
Notes on confidentiality
SGEN treats the difference between admin-side and public-side surfaces as a hard line. Anything pasted into a public-side field — page body, post content, popup copy, public form labels — is visible to anyone who can load the page. This includes search engines, archive bots, and any visitor with a browser.
A short list of fields that are public the moment they save:
- Page and post content body.
- Page and post titles, meta descriptions, and URL slugs.
- Form labels, placeholder text, and help text on public-facing forms.
- Popup copy.
- Footer and header text.
- Open Graph and social-share metadata.
- The Reason field on Blacklist entries.
- Internal notes on orders.
- The Users list itself.
- Activity Log entries.
A 30-day security check
If you want a small, repeatable rhythm, run this loop once a month:
- Open Users. Confirm every account on the list belongs to someone currently working on the site. Trash the rest.
- Click the Administrator role pill. Confirm the count matches the people who need admin rights.
- Open Blacklist. Sort by Hits descending. Anything with zero hits in 30 days is a candidate for removal — keep the rule only if it ties to a documented incident.
- Open the most recently edited record on the site. Read the revision history. If a change is recorded from a name you do not recognize, that is your investigation path.
Related reading
- Users — full user-account walkthrough.
- Blacklist — visitor blocking, hit counts, and the Test IP tool.
- UX — visitor-side interaction quality and consent surfaces.
- Updates & Stability — how platform updates remove the plugin-update vector.
- Performance & Reliability — platform-level stability that intersects with security continuity.
From Actual Feature Content Corpus (2026-04-27 export, page #19)
Group: Architecture / Reliability
Route seed: /security
Audience visibility: Client-facing default. Internal-only specifics live in support runbooks, not here.
This section preserves the original landing-page framing. It describes the documentation boundary for security material on the public docs site. The user-visible content above is what readers see and act on; this section is editor context for future revisions.
Documentation boundary
The Security section documents the access, dependency, hosting, disclosure, and control boundaries that govern how SGEN reduces risk and protects operational trust. Public readers should use this section for approved high-level security material. Internal readers can follow authenticated expansions into deeper operational records where visibility rules allow.
Page boundary
This page describes the access, dependency, and control behaviors a Site Owner can verify in the SGEN admin. It does not describe deployment topology, compliance attestations, or audit certifications — those are separate documents owned by the SGEN security team and are surfaced through procurement on request.
Related surfaces in the SGEN admin
Users, Blacklist, Activity Log entries (per surface), Site Backup / Restore, Per-post revisions, Tracking Consent (visitor-side), Site Settings.
Common questions from a compliance reviewer
A compliance reviewer or a procurement team will ask a small number of recurring questions about any platform that holds your data. The honest answers a Site Owner can give from the SGEN admin are:
"Who has admin access?"
Open Users, click the Administrator pill, hand over the resulting list. The list is the answer.
"How are sessions managed?"
A signed-in admin session lasts the duration of the browser session. Sign-out is one click from any admin page. A Site Owner can use Switch To to load the admin as another user for support, and every Switch To is recorded.
"How do you block hostile traffic?"
The Blacklist surface holds rules that are evaluated on every public and admin request before the page renders. Each rule carries a Reason annotation and a Hits counter so the rule's purpose and effectiveness are both visible.
"Where are changes recorded?"
Per-record revision history on every page and post. Site-level events (theme activations, role changes, bulk actions) appear in the Activity Log entries.
"What about data residency?"
The platform is fully managed. The deployment region for the underlying infrastructure is a product question best answered by the SGEN sales team — the Site Owner does not pick a region from the admin in the current shipped version.
"Can the site be exported?"
Yes. The site backup format is .sgen — a downloadable archive that captures the site state. The Site Backup surface in the admin produces the file on demand.
The pattern is the same across all of these: every answer points to a surface in the admin a Site Owner can reach without engineering involvement, and every claim is paired with the surface that proves it.
Where to ask if you need more
If a reviewer needs a specific compliance answer the admin cannot produce, ask the SGEN sales team for the current standing on that framework. The honest answer is preferable to a marketing claim that overshoots reality.
One paragraph on visitor-side trust
Security is not only about what happens inside the admin. The visitor side of the site carries its own surface: the consent banner that runs before tracking fires, the form-handling that stores submissions, the popup that asks for an email. Each of these surfaces is documented in its own page (Tracking Consent, Forms, Popups). Read this page first to understand the admin-side controls; read those pages next to understand what a visitor sees and what their data does after they hit submit.
When to escalate to support
Three signals are worth a support ticket rather than a self-investigation:
- An account you do not recognize appears in the Users list and you cannot identify who created it.
- The Activity Log shows a change made by a user whose name does not match anyone on your team.
- A Blacklist rule that should be blocking traffic is showing zero hits over a week despite confirmed visitor activity from the blocked range.
Closing thought
Security on an SGEN site is the sum of three habits: keep the Users list short, keep the Blacklist rules sharp, and read the change history before guessing what changed. None of the three is technically hard. All three are easy to skip when the day-to-day is busy. The 30-day check above is the small commitment that keeps the security posture from drifting.
The site is yours. The accounts are yours. The blocks are yours. The change history is yours. Treat the surface that way and you stay in control.
Use the per-area docs (Users, Blacklist, the per-record revision history) for the deeper walks; use this page as the map; use the 30-day check as the rhythm. The platform supports the work; the discipline is yours to keep.
A small team that runs the 30-day check honestly outperforms a large team that runs it once a year. Discipline beats scale on this surface.
That is the whole posture in one sentence.
Related reading
| Topic | |
|---|---|
| UX | |
| Blacklist | |
| What this covers | |
| --- | |
| What is this for? | |
| Good use cases | |
| What NOT to use this for | |
| How this connects to other features | |
| Before you start | |
| Where to find it | |
| Steps | |
| What success looks like | |
| What to do if it does not work | |
| Examples | |
| Property | Value |
| --- | --- |
| title | Security |
| audience | public |
| classification | PUBLIC |
| audit_at | 2026-05-14 |