Most security tools are sold on what the analyst sees. The dashboards, the triage queue, the report that lands in front of the board. Almost nobody talks about the person who keeps the lights on underneath all of it. That person is the platform administrator, and their job starts before the first finding is ever ingested and never really stops.
If you run PMAP for your organization, you are the one who decides how email leaves the system, how users authenticate, whether multi-factor authentication is mandatory, how many sessions a single account can hold open, what the product looks like to your colleagues, and whether the platform is even allowed to accept new writes today. That is a wide surface. The interesting thing about how PMAP handles it is that nearly all of it lives in one place and follows a small set of consistent rules.
This article walks the platform administrator’s view of PMAP. It covers the global settings surface, the live tests that keep you from guessing, the identity and session controls, the white-label branding, the Ed25519 license model with its global write gate, the infrastructure health dashboard, and the activity log that quietly records who did what. Every behavior described here comes from how the admin and license subsystems actually work. For the deeper architectural picture of how these pieces fit into the wider platform, the vulnerability management platform architecture pillar is the place to go next.
The Administrator’s Control Plane
PMAP gives the administrator a single control plane rather than a scatter of disconnected config screens. At the center of it is one row. The platform keeps a single global platform_settings record, and that one record governs every cross-cutting behavior the system has. SMTP relay, LDAP and Active Directory authentication, branding, storage, SLA deadlines, MFA enforcement policy, and concurrent-session caps all read from the same place.
This is a deliberate design choice with a real operational benefit. When configuration is centralized into one authoritative record, there is no question about which copy of a setting wins. A downstream subsystem does not keep its own private SMTP host. The email sender asks the admin service for the SMTP config. The session module asks for the concurrent-session cap. The authentication layer asks for the LDAP config and the MFA policy. The finding SLA engine asks for the default SLA hours. Each consumer reads through a clean interface, so the administrator changes a value once and every dependent subsystem sees the change.
Access to this control plane is locked down. Every /api/v1/admin route is gated by the platform_admin role. If an account does not hold that role, the admin surface simply is not reachable for it. This keeps the most powerful settings in the platform behind a single, explicit permission rather than leaking partial control to general users. The only exceptions served by the same handler are the self-service /me/stats and /me/activity endpoints, which any authenticated user can call to read their own profile data and their own activity, with no path to anyone else’s.
One Settings Surface, Many Subsystems
From the administrator’s chair the settings panel reads like a tabbed form. SMTP. LDAP. Branding. Storage. SLA. MFA. Session policy. Underneath, all of it is a read and write against that single platform_settings row, exposed through GET /admin/settings and PUT /admin/settings.
The breadth here is worth listing because it shows how much the administrator actually owns. The SMTP group covers host, port, user, password, sender address, and TLS. The LDAP group covers the server URL, bind credentials, base DN, user filter, the email and display-name attribute mappings, the group attribute, a default role, a JSON group-to-role map, and an auto-provisioning toggle. Branding carries the display name, logo URL, and a primary color. Storage and queue settings cover the storage path, retention days, worker count, and maximum upload size. SLA covers per-severity deadline hours plus a three-tier escalation ladder. MFA carries the mandatory toggle, the grace-period length, and the activation timestamp. Session policy carries the per-user concurrent-session cap.
That is a lot of power in one form, and power like that needs a safety mechanism. PMAP has one, and it is the kind of detail that saves an administrator from a bad afternoon.
Safe Partial Updates
The update path uses pointer-field semantics. The request that drives UpdateSettings is built so that only fields that were actually sent generate a database write. A field left absent generates no SET clause at all. This means a partial update touches only the values you intended to touch and leaves everything else exactly as it was.
The most important place this matters is credentials. For the SMTP password and the LDAP bind password, an empty string is treated as “no change,” not as “clear this.” So when the administrator opens the settings form, where those passwords are masked on read, and saves a change to the SMTP host without retyping the password, the password survives. To actually rotate a credential, the administrator sends a non-empty value. This contract is enforced on the server, not just hinted at in the UI, so it holds no matter what client is talking to the API. The result is that you can edit one corner of the configuration without fear of silently wiping a credential you could not even see on the screen.
SMTP and LDAP With Live Tests
Configuring an outbound mail relay or an LDAP bind by hand is one of those tasks where a typo costs you an hour. PMAP shortens the loop with live tests that verify your input before you commit to it.
For email, POST /admin/smtp/test sends a real test message to an address you nominate and returns success or failure inline. Crucially, this test does not change the saved configuration. It exercises the relay settings you want to use and tells you whether mail actually leaves the building, so you confirm deliverability before you rely on it for notifications and report delivery.
For directory authentication, POST /admin/ldap/test performs a live bind against the server using the credentials you entered and reports whether the bind succeeded, again without persisting anything. You learn that the bind DN and password are correct before you flip LDAP on for your whole user base. This separation of “test” from “save” is the difference between confident configuration and hopeful configuration.
LDAP itself goes well beyond a simple on switch. The administrator maps directory attributes to PMAP fields for email and display name, points at the right group attribute, and supplies a JSON group-to-role map so directory group membership translates into PMAP roles. An auto-provisioning toggle decides whether a successful LDAP authentication can create a PMAP user on first login. Taken together this lets an organization run identity out of its existing Active Directory or LDAP estate rather than maintaining a parallel set of local accounts. For practitioners who want the step-by-step mechanics of MFA, LDAP, and session management as a feature walkthrough, the identity, MFA, and session controls deep dive covers the procedure in detail. The administrator’s job, the one this article is about, is owning the policy these mechanics enforce.
Enforcing MFA and Session Limits
Two of the most consequential decisions an administrator makes are about how strongly accounts are protected. PMAP puts both under the same settings surface and gives each a sensible behavior model.
Multi-factor authentication can be made mandatory for all non-LDAP users with a single policy toggle. What makes the implementation considerate is the grace period. The grace window is measured from each user’s first login after the policy was activated, not from the wall-clock moment the administrator flipped the switch. The activation timestamp is recorded so the system knows when the policy went live. The practical effect is fairness. A user who happened to be on vacation when MFA was turned on still gets their full configured window once they next log in, rather than discovering the window already expired while they were away. The administrator sets one grace length and trusts the platform to apply it per user.
Concurrent sessions are capped through max_concurrent_sessions_per_user. This setting aligns with NIST SP 800-53 control AC-10, which is the concurrent session control requirement many organizations have to satisfy. The default cap is five active sessions per user. The session module reads the policy at login time through an interface, and when a user hits the cap, the oldest session is evicted as the new one is created. Setting the value to 0 disables enforcement entirely for organizations that do not want a cap. Because the session module reads the policy through an interface rather than importing the admin package directly, the two stay decoupled and the cap can change without code changes elsewhere. For the broader standards context, the NIST SP 800-53 catalog (NIST SP 800-53 Rev. 5) and the authentication guidance in NIST SP 800-63B are worth keeping on hand.
White-Label Branding
Not every administrative task is about security controls. Some of it is about making the platform feel like it belongs to your organization rather than to a vendor. PMAP exposes white-label branding through the same settings record, with three fields that matter: the platform display name, a logo URL, and a primary color.
These are not cosmetic afterthoughts buried in a corner. They surface to the frontend on every page load through GET /admin/settings, so the moment an administrator sets them, every user sees the organization’s name, logo, and accent color across the product. For an MSSP or a large enterprise rolling PMAP out to internal teams, this is the difference between a tool that looks borrowed and a platform that looks like part of the house. The administrator owns that identity and can change it without touching anything else, thanks to the same partial-update safety described earlier.
Licensing With Ed25519 Tokens
Licensing in PMAP is not a nag screen. It is a cryptographically enforced control that the administrator installs and the whole platform respects. The authoritative source of truth for every entitlement is a signed Ed25519 license token, and the public key used to verify it is compiled into the binary. There is no environment variable and no database field that can override the embedded key. That design closes the door on the most common way licensing gets quietly defeated.
Validation is fully offline. The offline manager verifies the token’s signature and parses its claims without calling any external service, which means air-gapped deployments are first-class rather than an afterthought. The token carries everything the platform needs to make entitlement decisions: a license and product identity, a plan name, the customer and company identity, a set of feature flags, a map of resource limits such as the asset seat count, an expiry timestamp, and a grace window. Business code across PMAP delegates to a single license provider rather than reading the token directly, so there is exactly one place the rules live.
The token moves through five computed states the administrator sees in the license card: valid, grace, read_only, expired, and unconfigured. The state is derived from the token’s expiry plus its grace window. A valid token is in good standing. A token past expiry but still inside its grace window reports grace and continues to function for both reads and writes. Once the grace window is exhausted the platform moves to read_only. Past expiry plus grace it is expired. An issuer can also revoke or suspend a token, and either of those is an immediate block. An unconfigured platform that has never had a token installed reports unconfigured.
Installing a token is one call. PUT /admin/license validates the inbound token’s signature before it persists anything, so a tampered or unsigned token is rejected at the door with a 400 rather than being stored and causing trouble later. There is one deliberate allowance: a token with a valid signature that happens to be expired is accepted, because that is exactly the situation a disaster-recovery re-issue needs to support. On a successful write the provider is refreshed immediately, so the new claims take effect at once instead of waiting for the background cache cycle that otherwise runs every five minutes.
The Global Write Gate
The part of licensing that an administrator most needs to understand is what happens when a license is not healthy, because it changes how the whole platform behaves. PMAP applies a LicenseGate middleware to every authenticated write path. Any POST, PUT, PATCH, or DELETE passes through this gate. When the license is in read_only, expired, revoked, or suspended state, those mutations are blocked with an HTTP 403 and a message that names the reason.
Read paths are treated differently and on purpose. GET, HEAD, and OPTIONS requests always pass through, unconditionally. The design intent is clear and humane. Even when a license has hard-expired, operators keep full read access to their own data. You can still see your findings, your assets, your reports, and your audit history. You simply cannot create or change anything until the license is restored. Data is never held hostage; only new writes are paused.
There is one route deliberately exempt from the gate, and it is the one that matters most in a crisis. The license installation endpoint itself is not blocked by LicenseGate. That exemption is what lets a platform administrator always install a fresh token to recover from an expired or revoked state, even when every other write in the system is paused. Without that carve-out, an expired license could lock the platform so completely that you could not even fix it. With it, recovery is always one upload away.
The other enforced dimension is the asset seat quota. The license carries an asset limit, and the asset service checks it on every create and import path through CheckLimit("assets", currentCount). The limit is inclusive, so a limit of N permits up to N total asset rows and the check rejects when the live count meets or exceeds the cap. The same quota function guards the scanner importers, so the six scanner integrations cannot quietly push the asset count past the licensed seat count during ingestion. The license card returns the live asset usage alongside the status in a single response, which is why the administrator sees a usage-versus-quota progress bar without a second round-trip to the server.
System Health at a Glance
An administrator who cannot tell whether the platform is healthy is flying blind. PMAP’s health dashboard answers that question directly with GET /admin/health. It runs an aggregated check across four components and returns a per-component status plus an overall roll-up.
The four components are the ones that actually keep the platform standing. The database is checked for latency. Redis is checked for TCP reachability. Object storage, backed by MinIO, is checked over HTTP. The queue status is derived from the database. Each component reports healthy, degraded, or unhealthy, often with a latency figure, and the overall field rolls those up into a single read. In the UI this becomes four tiles the administrator can scan in a second to know whether something underneath needs attention before users start noticing.
Alongside infrastructure health, the administrator gets an integration health listing. This enumerates every configured integration with a connectivity status of connected, error, or unknown. For a platform whose whole value depends on pulling scan data from multiple vendors and pushing tickets and signals outward, knowing at a glance which connectors are actually reachable is exactly the kind of operational visibility the administrator needs. A scanner that has quietly stopped talking shows up here rather than as a mysterious absence of new findings.
The Activity Log as a System of Record
Underneath everything the administrator configures, PMAP keeps a record of what happened. The activity log is the platform’s system of record for user actions, and the administrator’s view of it is the unified feed of every auditable action any domain has written.
The admin activity feed is cursor-paginated and filterable, served by GET /admin/activity-logs. An administrator can narrow it by user, by entity, by entity type, and by an action substring, then page through the results with a stable cursor. The detail that makes this feed genuinely usable rather than a wall of identifiers is server-side name resolution. The log stores polymorphic references to whatever entity an action touched, and the platform resolves the human-readable entity_name for assets, findings, projects, scans, users, companies, teams, roles, rules, runbooks, reports, and campaigns before the response goes out. The administrator reads “this user changed the status of this named finding” rather than “this UUID acted on that UUID.” That resolution happens once, on the server, so the UI does not have to fan out into extra lookups to make the feed readable.
The same handler offers a self-service slice. GET /me/activity returns the calling user’s own activity, with the user ID pinned from the authenticated token claims so there is no way for one user to read another user’s feed through it. The administrator gets the whole picture; an individual user gets only their own.
What makes this log trustworthy is how it is written, and that is the quiet engineering story behind the feed. Activity events flow through an async audit queue. The non-blocking Log call enqueues an event, and a background worker drains the buffer in batches, writing many events in a single network round-trip every couple of seconds or once a batch fills. This keeps logging off the hot path so recording an event does not slow down the action that caused it.
The compliance-critical detail is that the queue never silently drops an event. When the in-memory buffer is full, instead of discarding the event the system falls back to a synchronous single-row insert and logs a warning. On a graceful shutdown the queue drains fully before the process exits. The reasoning is straightforward. For organizations that have to satisfy frameworks like SOC 2 and ISO/IEC 27001, an audit trail with gaps is worse than useless. PMAP chooses completeness over raw throughput, accepting a brief synchronous write under pressure rather than ever losing the record. For the auditing and accountability requirements this maps to, the NIST SP 800-53 AU control family is the relevant reference, and the framework expectations behind it are described in ISO/IEC 27001:2022.
Bulk Rule Re-Evaluation and Revoke
The last piece of the administrator’s toolkit is the heaviest. When the rules that govern how findings are classified and mutated change, the administrator sometimes needs to apply that change across findings that already exist. PMAP handles this with two long-running background pipelines built for scale.
Bulk rule re-evaluation re-runs the rule engine across all findings that match an optional filter by rule, company, or asset. The administrator triggers it through POST /admin/rules/re-evaluate and the platform returns a 202 for a genuinely new job or a 200 when an equivalent job already exists, because the engine supports idempotency keys so a client retry does not spawn a duplicate run. A partial unique index enforces one active job per rule at a time, while full-sweep jobs that target no specific rule are allowed to overlap across administrators. The job is detached from the HTTP request so an administrator clicking the button and then navigating away does not cancel a run that might take minutes. It cursor-paginates through findings in batches of a thousand, and it polls for cancellation between batches, so a cancel request takes effect within roughly one batch’s evaluation time rather than waiting for the whole sweep to finish. Throughout the run the administrator polls a single endpoint to watch total, progress, applied, and error counters climb, which is what drives the live progress bar in the UI without any streaming.
The companion pipeline is async rule revoke. When a rule is disabled, the changes it previously made to findings need to be unwound, and across a large estate that can mean reverting mutations on a hundred thousand findings or more. The revoke engine is launched internally by the rule domain rather than as a direct admin endpoint, and it runs the same detached, batched, cursor-paginated pattern, tracking progress in its own job table. A safe mode checks each finding’s current state before reverting so it does not stomp on changes that happened since, while a force mode reverts unconditionally. The rule is only marked as revoked after a full clean pass. For an administrator, the value is that a rule change does not mean a manual cleanup. The platform carries the consequences of the change through the existing data set on its own, with progress you can watch and a job record you can inspect.
How PMAP Gives the Administrator Full Control
Step back from the individual features and a pattern emerges. PMAP treats the platform administrator as a first-class operator rather than an afterthought. The configuration lives in one authoritative record. Updates are partial and safe so you can edit one thing without breaking another. The risky settings come with live tests so you confirm rather than guess. Identity controls like MFA and session caps map to recognized standards and behave fairly. Licensing is a real cryptographic control that protects reads even when it pauses writes, and it always leaves you a recovery path. Health is one screen. The audit trail is complete by design. And the heavy maintenance jobs run in the background with progress you can see.
Each of these is grounded in how the admin and license subsystems actually behave, not in a marketing promise. The single settings row, the pointer-field updates, the SMTP and LDAP tests, the per-user MFA grace timer, the AC-10 session cap, the Ed25519 token with its five states and global write gate, the four-component health check, the name-resolving activity feed with its never-drop audit queue, and the two bulk job engines are the concrete pieces that add up to a control plane an administrator can actually run a platform from.
If you want to see how this administrative layer connects to ingestion, correlation, triage, and remediation across the rest of PMAP, the vulnerability management platform architecture pillar lays out the full picture. For the hands-on identity mechanics, the MFA, LDAP, and session management walkthrough and the license enforcement deep dive go a level deeper into two of the controls described here. And if your decision is still whether to build this yourself or adopt a platform that already solves it, the build versus buy comparison is the right place to weigh it.
