Trust & Security
Monitoring does not need the keys to your estate.
Many monitoring and management platforms combine visibility with powerful control.
That can be exactly what you need.
PingMyThing deliberately takes a narrower approach.
Its normal visibility path does not need to become your remote-management plane.
The security idea is restraint
Collect less
Only the operational information the question requires.
Control less
Visibility does not need remote shell, patching or arbitrary execution.
Separate deliberately
Projects, tokens and audiences can remain bounded.
Start by collecting less.
PMT's first security decision happens before encryption or access control:
What information is actually required for this operational question?
If the useful result is free disk space = 7.4 GB, PMT does not also need user files, broad software inventory, event logs and unrelated machine telemetry.
select deliberately → collect less → transmit less → store less → expose less
Visibility and control are separate.
PMT does not require its normal monitoring path to provide remote shell access, arbitrary remote execution, patch management, remote desktop or estate-wide remediation.
If remote administration is required, use an appropriate separately secured tool.
This separation reduces unnecessary coupling between visibility and privileged control.
Bound the access you actually need.
Security controls matter, but they do not justify sending more information than the operational job requires.
SCOPED ACCESS & PROJECT SEPARATION
PMT supports scoped token access and separate projects for different customers, systems or operational subjects.
Token lifecycle controls include expiry, rotation/deprecation, suspension and revocation.
Where audiences need different information, separation should normally happen at project/token boundaries rather than through a large central permission model around every station and check.
CREDENTIAL & STORAGE CONTROLS
The current design uses HMAC-based token aliases, Argon2id verification, optional PIN protection, scoped read/write permissions and encryption for recoverable credentials and selected sensitive stored fields.
API redaction and query-free access logging reduce credential exposure, while operational diagnostic logging remains separately controlled and retained for support/security purposes.
Telemetry values themselves are not encrypted by default.
Do not send sensitive information merely because the service has security controls.
OPAQUE IDENTIFIERS ARE NOT ENCRYPTION
Opaque identifiers can reduce how much human meaning appears in raw telemetry.
That can be useful. But if the mapping is obtained elsewhere, the meaning may become obvious.
Semantic compartmentalisation is not a substitute for encryption and access control.
Defined retention, not assumed permanence.
PMT uses defined retention rather than assuming operational telemetry should remain forever.
If you require immutable legal evidence or indefinite archival storage, use a system designed for that role.
GDPR by design, not as a badge
PMT is designed around data minimisation, scoped access, encryption, retention and project separation.
Designed around data minimisation and GDPR-by-design principles.
Software alone cannot make every use automatically GDPR compliant.
PMT is not risk-free.
Possible consequences of compromise could include loss or corruption of visibility, false reported state, exposure of permitted operational data, compromised credentials or disruption of access.
The security proposition is not: PMT cannot be compromised.
It is:
Do not give the monitoring layer more data, privilege or control than its job requires.
Keep the operational question smaller than the estate.
Collect only what the selected check requires. Keep control in the tools built for control.
Do not send sensitive data merely because PMT can receive data.