Token storage and rotation
Treat PMT tokens like credentials
PMT tokens control where signals are sent and which views can read stored signal data.
Keep tokens out of public scripts, screenshots, tickets and documentation. Store them where they can be protected, rotated and revoked without rewriting every check.
Good token handling is part of keeping PMT small, safe and operationally useful.
Core rule
Use the narrowest token that fits the job.
Send token
Used by a check, script, site, device or process to report into a project.
Read token
Used by a person, browser view or tool to read selected signal data.
Scope matters
Keep customers, sites and use cases separated with project-specific tokens.
When token storage matters
Token handling matters most when checks are repeated, shared, deployed widely or expected to last.
- Windows starter checks pushed by Group Policy
- scripts running as scheduled tasks or cron jobs
- customer or branch deployments
- WordPress or website-side signals
- API/CLI readback into another tool
- temporary assessment checks that must be removed cleanly
What poor token handling causes
- tokens copied into old scripts and forgotten
- one exposed token affecting too much
- hard rotation because the token is embedded everywhere
- unclear ownership of customer or project access
- temporary checks that outlive the investigation
A token strategy does not need to be complicated. It does need to be deliberate.
Storage options
Choose the simplest storage method that fits the environment and risk.
Registry
Useful for Windows scheduled tasks and Group Policy deployment.
HKLM\SOFTWARE\PMT\Token
Better for rotation than embedding the token inside every script body.
Environment variable
Useful for scripts, cron jobs, containers or simple shell-based senders.
PMT_SEND_TOKEN
Keep it out of public examples and committed files.
Protected config or secret store
Better for production integrations, applications and shared environments.
Use the secret/config system your environment already trusts.
Inline token
Acceptable only for quick tests or short-lived checks where the exposure is understood.
Do not treat inline tokens as a good default for reusable or widely deployed scripts.
Split token / PIN pattern
Where supported, a broad token plus local PIN-style protection can reduce accidental exposure.
Use only where the operational model is clear to the people maintaining it.
Windows registry pattern
For Windows scheduled checks, storing the send token in a registry value keeps the token out of the script body and makes rotation easier.
Typical location:
HKLM\SOFTWARE\PMT\TokenA scheduled task or script reads the token at runtime and sends the selected signal.
Why this helps
- scripts can be inspected without exposing the token directly
- rotation can update a registry value rather than every script
- Group Policy or admin tooling can manage deployment
- temporary checks can be removed more cleanly
This does not protect against administrators who already control the endpoint. It reduces accidental spread and improves maintainability.
Rotation, revocation and expiry
Tokens should not be treated as permanent fixtures. Rotate or revoke when the access purpose changes.
Rotate
Replace a token while keeping the check or project in service.
Useful after staff changes, handover, customer changes or periodic hygiene reviews.
Revoke
Disable a token when it is exposed, no longer needed or tied to a completed assessment.
Revocation is cleaner when each project and purpose has its own token.
Expire / TTL
Use expiry where access should be temporary.
Assessment checks, customer-shared views and short-term investigations are good candidates.
Suggested practical pattern
- Create or choose the project.
- Use a project-specific send token.
- Store the token in registry, environment variable or protected config where practical.
- Deploy the starter check or custom sender.
- Document what the signal means and how to remove it.
- Rotate or revoke the token when the purpose changes.
Temporary assessment pattern
For client assessment or problem solving, use one or more transparent checks to surface hard-to-reach signals from the client setup.
Use a temporary token or project where appropriate. Remove the scheduled task, script, config and token access when the assessment is done.
Do not let temporary checks become forgotten permanent infrastructure.
Do not do this
- paste live tokens into public documentation
- commit tokens to GitHub or a shared repo
- reuse one token across unrelated customers
- send customer secrets as station names or signal names
- leave assessment tokens active after the work is complete
- use read tokens where a sender only needs send access
Keep names safe too
Token safety is not only about token values.
Station names, signal names, tags and project labels should not include secrets, personal data or confidential client information unless there is a clear and documented reason.
Prefer stable, boring labels.
Group Policy deployment
Deploy checks across Windows systems with normal admin tooling.
Keep token handling boring
Use narrow tokens. Store them outside reusable scripts where practical. Rotate, revoke or expire them when their purpose changes.