Test and Synthetic Accounts Governance Guide: Controlling Accounts Nobody Thinks Are Real

Test, demo, QA and synthetic monitoring accounts are created quickly, exempted from controls "because they are only for testing", and then forgotten, which makes them some of the easiest real credentials an attacker can find. Microsoft's own 2024 incident began with a password spray against a legacy, non-production test tenant account without MFA, and pivoted through a legacy test OAuth application that still had elevated access to the corporate environment. This guide covers the kinds of test and synthetic accounts organisations run, where they go wrong, how to govern their lifecycle, how to keep them out of production or control them when they must be there, and how to find the ones already in place. It is for identity governance teams, platform and QA leads, and security teams that own access reviews. Isolation of machine identities between environments is covered in the OWASP NHI Top 10 NHI8 Environment Isolation Guide; this page is about the accounts themselves.

Key takeaways

• A test account is a real account. If it can authenticate to a real system, it needs an owner, an expiry, MFA or a stronger alternative, and a place in access reviews, whatever its name says.
• Non-production is not a boundary if identities cross it. Test tenants, apps and accounts that can reach production turn the weakest environment into the entry point.
• Synthetic accounts in production are legitimate but special. Monitoring and probe accounts need dedicated, narrowly scoped identities, conditional access tied to their source, and credentials held in a vault.
• Expiry by default beats clean-up campaigns. Accounts created for a test should be born with an end date and disabled automatically when it passes.
• Discovery is half the work. Naming patterns, creation source, sign-in inactivity and MFA exclusion lists find most forgotten test accounts quickly.

What counts as a test or synthetic account

Many of these are human-shaped accounts used by scripts, which places them squarely in non-human identity governance: no single person logs on with them, but they hold real access.

Why test accounts become breaches

• Exemptions: test accounts are excluded from MFA, password policy, conditional access or monitoring to keep automated tests running, and the exclusions outlive the tests.
• Trust paths: a test tenant is weakly controlled, but an app or account in it has rights in production. Microsoft's responder guidance describes Midnight Blizzard finding a legacy test OAuth application with elevated access to the corporate environment, creating further OAuth applications, and using the legacy app to grant the Office 365 Exchange Online full_access_as_app role. See the Microsoft Midnight Blizzard Breach 2024.
• No owner: the engineer or contractor who created the account has moved on; nobody can say whether it is still needed, so nobody deletes it.
• Predictable credentials: names such as test1, qa_admin or demo and shared passwords are exactly what password spraying tries.
• Production data in test: test environments seeded with copies of production data make a test compromise a data breach even without a path to production.
• Invisible in reviews: access reviews target employees from the HR feed; accounts with no manager or HR record are skipped.

Governance model

Give every test and synthetic account the same lifecycle attributes you give a service account, plus an expiry:

A naming and tagging standard makes all of this enforceable. See the NHI Naming and Tagging Standard Template for a template you can adapt.

Keeping test accounts out of production

1. Separate identity boundaries: run non-production in separate tenants, directories or accounts, with no app registrations, guest links or federation trust from non-production into production. NIST SP 800-53 CM-2(6) calls for development and test baselines managed separately from operational baselines.
2. Block crossings by policy: deny sign-in to production applications for accounts tagged as test, except approved synthetic accounts. The OWASP NHI8 guidance says non-production identities should not be able to access or interact with production resources.
3. Remove before go-live: make "test accounts and test data removed" a release gate for every system entering production. Payment card environments under PCI DSS v4.0.1 already require this (Requirement 6.5.6).
4. Treat production copies carefully: SP 800-53 SA-3(2) requires approving and controlling live data in pre-production and protecting that environment at the same impact level. If you copy production data into test, apply production identity controls to test.
5. Apply the same baseline to test tenants: MFA for every account, legacy authentication blocked, admin consent workflow on. A test tenant with weaker controls but production reach is the Midnight Blizzard pattern.

Governing synthetic and monitoring accounts in production

Some accounts must exist in production: availability probes, end-to-end transaction monitors, accessibility and regression suites run against live systems, and app store review accounts. Control them as privileged non-human identities:

• Dedicated per purpose: one account per monitor or suite, never shared with people or reused across products.
• Least privilege: the lowest role that completes the transaction; no admin roles for availability checks.
• Conditional access by source: instead of a blanket MFA exclusion, allow the account to sign in only from the monitoring platform's known egress addresses or managed workloads, and block everything else.
• Stronger authentication where possible: certificate-based or FIDO2-backed authentication for automation that supports it, or workload identity instead of a user account where the monitored system accepts it.
• Vaulted, rotated credentials: store secrets in a vault integrated with the monitoring tool, and rotate on a schedule and on any change of tooling vendor.
• Data limits: synthetic accounts should operate on synthetic data, such as dedicated test customers or zero-value orders, so a compromise cannot read real records.
• Distinct telemetry: tag their activity so it is excluded from business analytics but included in security monitoring.

Decision guidance: if a probe only needs to know a page loads, use an unauthenticated health endpoint and no account at all. If it must exercise login, use a dedicated account with source-restricted conditional access. If it must exercise privileged functions, run it in staging instead, or time-box a privileged synthetic account behind just-in-time elevation. Small organisations can usually remove most synthetic accounts by using health endpoints; large ones need a register of synthetic accounts reviewed quarterly.

Finding the test accounts you already have

1. Search by name: look for test, qa, demo, temp, sandbox, load, synthetic, pentest, trial and similar patterns in user principal names, display names and app registration names, across every directory, tenant and SaaS application.
2. Search by creation source: accounts created by scripts, bulk import or setup tools rather than the HR-driven provisioning flow.
3. Search by missing attributes: no manager, no employee ID, no department, no HR record.
4. Search by exemption: members of MFA exclusion groups, conditional access exclusions, password-never-expires settings and legacy authentication allow-lists.
5. Search by inactivity: Microsoft notes there is no built-in inactive accounts report in Entra and suggests a 90 to 180 day window; the lastSuccessfulSignInDateTime property (Entra ID P1 or P2) supports this. Include non-interactive sign-ins so automated accounts are not wrongly marked inactive.
6. Search the app layer: test app registrations and service principals, especially those holding high-impact application permissions. Microsoft's responder guidance specifically calls for reviewing apps holding EWS.AccessAsUser.All or full_access_as_app.
7. Search non-production tenants for production reach: enumerate apps, guests and cross-tenant access settings that connect test tenants to production.

Then triage: disable first, wait for complaints for a defined period, delete after. Disabling is reversible; deletion of an account that a forgotten monitor depended on is not always.

Implementing the programme

1. Policy and standard (month 1): publish the account types, required attributes, expiry rules and naming standard, and add "remove test accounts" to release checklists.
2. Discovery (months 1 to 2): run the searches above and build an inventory with an owner for each account.
3. Quick wins (month 2): disable inactive and ownerless test accounts in production, enable MFA in test tenants, remove test apps with production permissions.
4. Controls (months 2 to 4): replace MFA exclusions for synthetic accounts with source-restricted conditional access, move credentials into a vault, apply automatic expiry through your IGA or lifecycle tooling.
5. Prevention (ongoing): provide self-service creation of test accounts with expiry built in, so engineers have no reason to create unmanaged ones, and block creation of accounts that do not match the standard.
6. Review (quarterly): include test and synthetic accounts in access reviews with their owners as reviewers. See the NHI Ownership Attestation Campaigns Guide.

Detection and measurement

• Password spray against test accounts: many failed sign-ins across accounts matching test naming patterns, especially from residential or anonymising networks, which Microsoft reports Midnight Blizzard used.
• Test identities in production: sign-ins to production apps by accounts tagged test outside the synthetic allow-list.
• Synthetic accounts off-source: any sign-in from outside the monitoring platform's addresses.
• Permission changes on test apps: new credentials, consent grants and application role assignments on test app registrations.
• Reactivation: disabled test accounts being re-enabled.

Metrics:

• Test and synthetic accounts with a named owner and expiry date (target 100%).
• Test accounts enabled in production that are not on the synthetic allow-list (target zero).
• Test or synthetic accounts excluded from MFA without compensating source restrictions (target zero).
• Test applications with production permissions (target zero).
• Median age of test accounts, and count past expiry still enabled.

Framework mapping

Common failure patterns

• Test tenant with production reach: a legacy test app or account in a weakly controlled tenant holds rights in production, the pattern in the Midnight Blizzard incident.
• Permanent MFA exclusions: a synthetic or QA group excluded from MFA in a conditional access policy grows to include accounts nobody recognises.
• Shared test credentials: one password used by a whole QA team and pasted into test scripts in repositories.
• Admin roles for testing admin features: test accounts given Global Administrator or Domain Admins to test one function and never reduced.
• Penetration test accounts left behind: accounts created for an engagement remain enabled after the report is delivered.
• Clean-up without prevention: a one-off campaign removes hundreds of accounts, then the same number reappear because creating an unmanaged test account is still the easiest option.

Lessons from incidents

The Midnight Blizzard case shows each failure in sequence: a non-production account without MFA, a slow password spray from rotating residential addresses, a forgotten test application with corporate privileges, and then new applications and high-impact permissions created from that foothold. Microsoft's own recommendations afterwards map directly onto test account governance: audit the privileges of all identities and apps, remove permissions that are no longer needed, require MFA everywhere, limit application access to specific mailboxes and monitor for high-impact permission grants.

Practitioner checklist

• Publish a test and synthetic account standard with types, owner, environment, expiry and naming requirements.
• Inventory test accounts and test applications across every directory, tenant and SaaS application.
• Disable ownerless, expired and inactive test accounts, then delete after a defined grace period.
• Remove app registrations, guest links and trust that let non-production tenants reach production.
• Enforce MFA and block legacy authentication in test tenants to the same standard as production.
• Replace MFA exclusions for synthetic accounts with source-restricted conditional access and vaulted credentials.
• Make removal of test accounts and test data a release gate for every system entering production.
• Give engineers self-service test accounts with automatic expiry.
• Include test and synthetic accounts in quarterly access reviews with their owners.

Standards and references

• OWASP: Non-Human Identities Top 10 2025, NHI8 Environment Isolation
• Microsoft Security Blog: Midnight Blizzard, guidance for responders on nation-state attack
• Microsoft Learn: How to manage inactive user accounts
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• OWASP: Application Security Verification Standard 5.0

Related NHI Mgmt Group resources: OWASP NHI Top 10 NHI8 Environment Isolation Guide · Microsoft Midnight Blizzard Breach 2024 · NHI Ownership Attestation Campaigns Guide · APT29 (Midnight Blizzard) Threat Actor Profile