SecQon Rules of Engagement and Testing Authorisation

Effective date: 22 September 2026 · Version: 2026-09-v9

This document (the "RoE") is the operative authorisation under which Infiqon Private Limited ("Infiqon", "we", "us") conducts security testing against your systems through SecQon. It forms part of the SecQon Terms of Service (the "Terms") and takes precedence over them in respect of the conduct and scope of testing. Capitalised terms not defined here have the meaning given in the Terms.

Read this as you would read a penetration testing authorisation letter, because that is what it is. It is the document that makes our testing of your systems lawful, and the document we will rely on if someone challenges it.

Versions. This RoE is versioned and hashed, and every acknowledgement and standing authorisation you give is pinned to the version in force when you gave it (Sections 4A.4, 4E.10 and 12.2). When we issue a new version you are asked to accept it before your next Scan, and testing first described in a later version is authorised only from your acceptance of it (Section 12.4).

1. Authorisation granted

1.1 You authorise and instruct Infiqon, and its personnel and automated systems acting on its behalf, to conduct external, non-destructive security testing against each of your Authorised Assets, for the duration set out in Section 10, using the methods described in Sections 4, 4A, 4B and 4D, subject to the acknowledgements those Sections require.

1.2 This authorisation is given by you as the party entitled to grant it, and extends to the specific activities described in this RoE and to nothing else.

1.3 This is a standing authorisation. Once an Asset is verified and your subscription is active, scheduled and continuous testing may run without a further prompt, until you remove the Asset, pause monitoring, or your verification lapses.

1.4 The authorisation is layered. Accepting this RoE authorises the methods in Section 4 only. Each of the following requires its own, separate, affirmative acknowledgement from you — given either for the specific Scan to which it applies, or in advance for a specific Asset under Section 4E — and none is implied by any other:

Deep profile proof-of-exploit testing — Section 4A;
penetration-test tier attack payloads, WAF testing and API authorisation testing — Section 4B, which is only available on a Deep Scan for which the Section 4A acknowledgement has also been given;
authenticated testing using credentials you supply — Section 6, and, where combined with the penetration-test tier, the writes to your own records described in Section 4D.

Where an acknowledgement is absent, the corresponding module does nothing and no corresponding traffic leaves our systems.

2. Your warranty of authority

2.1 You represent and warrant, on each occasion you add an Asset, complete verification, launch a Scan, give an acknowledgement under Section 1.4, or allow a scheduled Scan to run, that:

you own the Asset, or hold current, express, written authorisation from its owner and operator to authorise third-party security testing of it of the kind described in this RoE, including, where you give the Section 4B acknowledgement, penetration testing with genuine attack payloads, and, where you supply credentials, the authenticated testing described in Section 6 — including, where you give a standing authorisation under Section 4E, its recurring and unattended use;
you have authority to bind the entity on whose behalf you act;
you have obtained any permission required by the hosting, cloud, CDN, WAF, DNS or managed service provider that serves the Asset, and given any notice their acceptable-use or penetration-testing policy requires, before the testing in question runs (see also Section 4C.2);
the testing described here is lawful in every jurisdiction in which the Asset is hosted, operated or reachable; and
the Asset is not in a prohibited category under the Acceptable Use Policy.

2.2 Technical verification is not legal authority. Proving control of a DNS record or a web root demonstrates that you can place a token; it does not demonstrate that you are entitled to authorise an attack. Section 2.1 is what we rely on for that, in every case.

2.3 You will keep evidence of your authority for as long as the Asset is in your account and for three years afterwards, and will produce it within five business days of a reasonable request from us, including in response to an abuse complaint.

3. Scope

3.1 In scope

Only Verified Assets in your account, at the time each Scan runs. Nothing else, ever.

3.2 Out of scope — always

Any Asset that is not verified, or whose verification has lapsed.
Subdomains of a verified apex domain. Verifying example.com does not authorise testing of admin.example.com. Each host is verified separately.
Any host, IP or service discovered during reconnaissance but not verified. Discovered surface is shown to you as "verify to test" and receives no test traffic.
Anything excluded by the Acceptable Use Policy.
Internal, private or non-internet-facing systems.

3.3 How scope is enforced

Scope is enforced at the network egress boundary of the scan worker, not merely in the logic that chooses what to test. Every outbound connection is checked against your verified-asset allowlist and the resolved address is pinned; anything out of scope is blocked and recorded, even if it was introduced mid-scan by reconnaissance, a redirect, a DNS change or a bug in our own code. This applies equally to the third-party scanning engine used under Section 4B, whose every request is routed through the same boundary. Denials are written to the audit log.

3.4 Changing scope

Add an Asset and verify it to bring it into scope. Remove an Asset to take it out of scope immediately.

4. Methods we use

Depending on the scan profile you choose and the acknowledgements you give, testing may include:

Passive reconnaissance — DNS records, certificate transparency logs, public metadata, technology fingerprinting.
Surface enumeration — subdomain discovery, port and service discovery, endpoint and content discovery on your verified hosts.
Transport and configuration testing — TLS configuration and certificates, security headers, cookie flags, DNS hygiene, exposed development and administrative interfaces.
Vulnerability testing — checks for known vulnerable software versions and for common web vulnerability classes, including the OWASP Top 10.
Bounded exploitation for validation — a limited, minimal attempt to confirm whether a candidate issue is genuinely exploitable, using the smallest payload that demonstrates the point and nothing more. On the Deep profile, and only after you give the intrusiveness acknowledgement described in Section 4A — per Scan, or in advance for that Asset under Section 4E — this is performed by the automated engine. It never exceeds the prohibitions in Section 5. On the other profiles, no proof-of-exploit traffic is sent.

A Finding's confidence label means exactly this, and is set from what the engine actually did — never by assumption:

confirmed — the Finding was re-tested against your live asset after it was first observed, and the condition was reproduced, through the same scope guard and rate limits; the reproduction transcript is recorded in the Finding's evidence. Reproduction is the only route to confirmed — an asset merely being reachable is never enough.
likely — observed once on a strong signal but not reproduced on re-test.
unconfirmed — everything else, including a scanner status note that recorded no observation.
Authenticated testing — only where you have explicitly supplied credentials for that purpose and given the authenticated-testing acknowledgement — per Scan, or in advance for that Asset under Section 4E — subject to Section 6. This includes authenticated crawling: your supplied session is carried by the crawler so that pages and endpoints behind your login are discovered and tested.
Continuous monitoring and change detection — periodic re-testing and alerting on new exposure.
Active penetration testing with genuine attack payloads — only under the penetration-test tier and its separate acknowledgement, subject to Section 4B.
Web application firewall effectiveness testing — only under the penetration-test tier, subject to Section 4B.4.
API authorisation testing — object-reference enumeration and mass-assignment probing against endpoints your own API schema declares, only under the penetration-test tier, subject to Sections 4B.5 and 4D.
Out-of-band confirmation of server-side request forgery — where enabled, subject to Section 4B.6.

Sections 4A, 4B, 4C and 4D are part of this Section 4 and are to be read with it.

4A. The Deep profile and your intrusiveness acknowledgement

The Deep scan profile is more intrusive than the other profiles, and is gated accordingly.

4A.1 What Deep does. In addition to the methods in Section 4 items 1 to 4, 6 and 7, Deep performs bounded, non-destructive proof-of-exploit testing: it sends the smallest crafted request that establishes whether a candidate issue is genuinely exploitable — for example, submitting a single inert, non-executing marker in a request parameter to determine whether it is reflected unescaped into a page. Except where you have also given the penetration-test acknowledgement under Section 4B, the payloads sent on a Deep Scan do not execute and do not carry a working attack; they exist only to demonstrate the condition. Where you have given the Section 4B acknowledgement, Section 4B governs the additional traffic sent.

4A.1A Form submissions on Deep. A Deep Scan may also submit forms on your Asset, by POST, without credentials and under the Section 4A acknowledgement alone. This is limited as follows: only a form the engine can positively identify as a search or query form is submitted — it must name a query in its action or a field, carry no password field and no file upload, have no more than four fields, and contain no word suggesting an action (such as delete, pay, checkout, sign-up, log-in, transfer or unsubscribe); anything not positively identified as a search is left alone. At most three forms are submitted per Scan, each once. The submission carries one inert marker in the query field and leaves every other field empty, so that nothing resembling a real record is created. If your Asset nonetheless stores search terms, the marker will appear in that store.

4A.2 It never exceeds Section 5. Deep testing is still bounded, rate-limited, and confined to your Authorised Assets. None of the prohibitions in Section 5 are relaxed for Deep — no destruction, no denial of service, no persistence, no lateral movement, no bulk extraction.

4A.3 It cannot run without your acknowledgement. Deep will not send a single proof-of-exploit packet unless you have acknowledged its intrusiveness — either for that specific scan, or in advance for that Asset by giving a standing authorisation under Section 4E. Either way this is a distinct, deliberate step, separate from the standing authorisation in Section 1: authorising us to test is not, by itself, permission to run intrusive testing. Without one of the two, the Deep exploitation module does nothing and no such traffic leaves.

4A.4 The acknowledgement is recorded. Your acknowledgement is written to the append-only audit log for that scan, together with the version and text hash of this RoE in force at the time (Section 12.2), so there is a durable record of exactly what you agreed to for each Deep scan. Where the scan ran under a standing authorisation, the record identifies that authorisation and the date you gave it.

4B. The penetration-test tier and your separate acknowledgement

4B.1 What it is. Where your plan or a one-off purchase includes it, and you have given the penetration-test acknowledgement for a specific Deep Scan — or in advance for that Asset under Section 4E — Infiqon performs active penetration testing of the Authorised Assets in that Scan. The acknowledgement is only available on a Deep Scan for which you have also given the Section 4A acknowledgement.

4B.2 These are real attacks. Unlike the testing described in Section 4A.1, the payloads sent under this Section are working attack payloads of the kind a hostile actor would send. The attack classes are:

path traversal and local file inclusion;
remote file inclusion;
server-side code injection;
operating-system command injection;
server-side template injection, including blind variants;
XPath injection;
XML external entity injection;
open (external) redirect;
CRLF and header injection;
server-side include injection;
SQL injection; and
reflected cross-site scripting.

A payload that succeeds may cause your application to read a file it should not, evaluate an expression, execute a command, make a request, or return data it should not — that is what the test is designed to detect. Attack classes not listed above are not used, and we will not add an attack class to this list without issuing a new version of this RoE.

4B.3 The limits on that testing. Testing under this Section:

uses a fixed allowlist of attack rules chosen by us; nothing runs that is not on it;
never uses a stored or persistent attack. No payload is used that is designed to remain in your application, database, logs-as-content, or another user's session. Stored and persistent cross-site scripting rules are excluded and their exclusion is enforced in code and by an automated test;
is confined to addresses on your Verified Assets that the Scan has already discovered; the attack engine does not crawl on its own;
passes every request through the scope boundary described in Section 3.3, under the same per-asset rate limits and scan windows as all other traffic;
remains subject without exception to Section 5; and
is materially longer and heavier than other testing. Expect a Scan under this Section to run for an extended period and to send substantially more requests to your Asset than a Scan without it.

4B.4 Testing your web application firewall. Where this tier runs, Infiqon also sends a fixed set of recognisable attack signatures — currently eight, representing path traversal, reflected cross-site scripting, SQL injection, operating-system command injection, template injection, a JNDI lookup of the kind used in the "Log4Shell" vulnerability, open redirect and CRLF injection — as ordinary query-string values in idempotent GET requests, after first sending a benign request for comparison. The express purpose of these requests is to be detected: we record which of them your firewall, CDN or edge blocked and report the result to you as a measure of that control's effectiveness. These signatures are not designed to extract anything from your Asset, and nothing your application returns in response to them is used as evidence of a vulnerability in it. They are sent in a parameter your application is unlikely to process, but a vulnerable application that does process or log them may react to them as it would to the equivalent payload under Section 4B.2. A signature that reaches your application is reported as a statement about your firewall, not as a vulnerability in your application.

4B.5 Object-reference enumeration. Where this tier runs and your Asset publishes an OpenAPI or Swagger schema, Infiqon sends sequential-identifier GET requests to endpoints that schema declares, together with a control identifier that should not exist, to determine whether object references are enumerable. Every such request is an idempotent read. Where you have supplied credentials under Section 6, these reads are made with that session and will retrieve real objects that account is permitted to see; where you have not, they are made anonymously. Whether one account can reach another's objects is not tested, because we hold only the credentials you supply and never a second account.

4B.6 Out-of-band confirmation. Server-side request forgery is confirmed by inducing your Asset to make a DNS or HTTP request to a collector operated by Infiqon and observing whether that request arrives. The collector answers at oast.secqon.com from an address separate from the scanning source in Section 4C.4, so an outbound connection from your Asset to that name is the result of this test. A request that arrives necessarily carries information about your infrastructure (for example, the address and software that made it) out of your network and to us; the collector holds it in memory only and discards it within one day, and we treat what we record from it as Customer Data under the Terms and the Privacy Policy. We do not use a collector operated by anyone other than Infiqon.

4B.7 The acknowledgement is separate and recorded. Neither the standing authorisation in Section 1, nor the Deep acknowledgement in Section 4A, nor a Deep standing authorisation under Section 4E, nor the authenticated-testing acknowledgement in Section 6 however it was given, authorises the testing in this Section. The penetration-test acknowledgement is a distinct step, given either for a specific Scan or in advance for a named Asset under Section 4E.4(b). Without it, no attack payload, no firewall signature and no API authorisation test leaves our systems. Your acknowledgement is written to the append-only audit log for that Scan together with the version and text hash of this RoE in force at the time (Section 12.2).

4B.8 Who may give it. By giving the penetration-test acknowledgement you confirm that you personally hold authority to commit the entity that owns or operates the Asset to penetration testing of it with genuine attack payloads, and that you have read this Section 4B and Section 4C. Infiqon may restrict the acknowledgement to the account owner or to designated roles, and may require a counter-signed engagement letter for particular Assets, customers or jurisdictions, in each case at its discretion.

4B.9 One-off purchases. Where you have purchased a single penetration-test report rather than a plan that includes this tier, the purchase is consumed when a Scan carrying the penetration-test acknowledgement is launched, whether or not the Scan completes for reasons within your control (including your stopping it, your Asset blocking our traffic, or your verification lapsing). The Refund and Cancellation Policy governs refunds.

4C. What this testing will look like to you and to others

This Section applies to every Scan carrying the penetration-test acknowledgement, and to the extent relevant to every Deep Scan. The first paragraph of Section 4C.1 applies to every Scan on every tier.

4C.1 It will trigger your security alerting. Every Scan other than the lightest, passive profile — on every tier, including the free one — sends traffic that a sensitive firewall or intrusion detection system may classify as an attack: probe values containing markup, requests for well-known sensitive paths such as /.git and /.env, checks for known vulnerabilities and default credentials, and a port scan. Expect a firewall alert from any such Scan, and read Section 7.2 before your first one.

Traffic sent under Section 4B goes much further. It is indistinguishable in your logs from a genuine attack, and part of it is intended to be detected. You should expect alerts from your web application firewall, CDN, intrusion detection and prevention systems, security information and event management platform, application error tracking, and any managed detection or response provider — including automated escalations and pages to on-call staff. You are responsible for informing the people who will see those alerts before the Scan runs, and for ensuring they are not treated or reported as a genuine security incident.

4C.2 You must notify your providers. Before giving the penetration-test acknowledgement for an Asset you are responsible for obtaining any consent, and giving any notice, required by the acceptable-use, security-testing or penetration-testing policy of every hosting provider, cloud provider, CDN, web application firewall vendor, DNS provider and managed-security provider that serves the Asset. Some providers require advance written notice or a scheduled window for testing of this kind; some prohibit it on certain plans. Where a provider suspends, throttles, blocks or terminates your service, or raises an abuse report, because of traffic you authorised under this RoE, that is a consequence of your authorisation and Section 8 and Section 11 apply.

4C.3 Shared infrastructure. You warrant that testing your Authorised Assets under Section 4B will not materially affect any third party that shares infrastructure with them — including other tenants of a shared host, load balancer, firewall, database or platform — and that you are entitled to authorise testing of that infrastructure to the extent the testing reaches it. If you cannot give that warranty for an Asset, do not give the penetration-test acknowledgement for it.

4C.4 Scanning source. All test traffic originates from a single dedicated address under Infiqon's control: 8.234.64.105 (Google Cloud, asia-south1, Mumbai). Use it to allow-list, annotate or correlate our traffic. If it changes, we will issue a new version of this RoE and notify account owners before the change takes effect. Traffic from any other source is not ours, however closely it resembles a SecQon Scan.

4C.5 Third-party reports to Infiqon. If a provider or third party reports to us that traffic from our systems is attacking an Asset, we may pause testing of that Asset and ask you for the evidence of authority referred to in Section 2.3. We will treat an inability to produce it as a revocation of authorisation for that Asset.

4D. Writes to your own records under the penetration-test tier

4D.1 What it does. Where you have supplied credentials for an Asset under Section 6, given the authenticated-testing acknowledgement, and given the penetration-test acknowledgement for the Scan, and the Asset publishes an OpenAPI or Swagger schema that declares an endpoint for updating the authenticated account's own record, testing may send a small number of PATCH or PUT requests to that endpoint, each carrying privileged field names (for example a role, an administrator flag or a verification state) with marked values, and then read the record back to determine whether the application accepted a field it should not.

4D.2 Its limits. These requests:

are made only to endpoints your own published schema declares as updating the current user, profile, account or settings;
are made only with, and only affect the record belonging to, the account whose credentials you supplied, and act only within that account's existing permissions;
are never POST or create operations, never delete, deactivate, revoke or destroy operations, and never touch another account's record; and
are subject in full to Section 5.

4D.3 What may change. If your application is vulnerable, a privileged field on the supplied account's own record will have been changed by the test, and the Finding will tell you exactly which field and to what value so that you can reverse it. If your application is not vulnerable, nothing changes. In either case the request itself is the evidence and is recorded in the Finding. A write of this kind is not a "destructive action" for the purposes of Section 5, and you accept its consequences under Section 8.

4E. Standing authorisation for scheduled intrusive and authenticated testing

Sections 4A, 4B and 6 require your acknowledgement before intrusive or authenticated testing runs. This Section lets you give that acknowledgement once, in advance, for a named Asset, so that the scheduled testing your plan provides can run on its cadence without prompting you for every Scan. It is entirely optional. If you give nothing under this Section, Sections 4A, 4B and 6 operate exactly as written and that testing runs only on a Scan you launch yourself.

4E.1 What it is. A standing authorisation is an affirmative, per-Asset instruction from you that an acknowledgement this RoE would otherwise require for each Scan — the one in Section 4A, the one in Section 4B, or the one in Section 6 — is given in advance for every scheduled Scan of that Asset, until you revoke it. Each is given separately and none is implied by another.

4E.2 It is separate, and never implied. A standing authorisation is not created by accepting this RoE, by the standing authorisation in Section 1.3, by verifying an Asset, by enabling monitoring, or by purchasing any plan. It is given by a distinct, affirmative act for a named Asset. Authorising us to test is still not, by itself, permission to run intrusive testing — this Section changes when you give that permission, not whether you must.

4E.3 It may only be given for a verified Asset. You cannot give a standing authorisation for an Asset whose ownership is not yet proven. We ask only once verification of that Asset has succeeded, so that whoever authorises intrusive testing of a host has first demonstrated control of it.

4E.4 Three levels, given separately.

a Deep standing authorisation supplies the Section 4A acknowledgement for scheduled Scans of that Asset;
a penetration-test standing authorisation supplies the Section 4B acknowledgement. It is available only for an Asset that already carries a Deep standing authorisation, only on a plan that includes the penetration-test tier, and it is never given by default or as part of (a);
an authenticated-testing standing authorisation supplies the Section 6 acknowledgement. It is independent of (a) and (b) in both directions: it neither requires nor implies them, because logging in as you and sending attack payloads are different things and consenting to one is not consenting to the other.

None implies another, and each may be revoked on its own.

4E.4A What the authenticated level does, and when. Unlike (a) and (b), which apply only to the periodic full re-audit, the authenticated-testing authorisation applies to every scheduled Scan of that Asset. That is deliberate and it is in your interest: the crawler carries your session on every request, so a Scan that authenticates finds materially more of your application than one that does not, and alternating between the two would make our own change detection report pages as appearing and disappearing when nothing about your application had changed.

On a scheduled Scan that is not also a Deep Scan, every authenticated request we send is a read. The engine that performs it can issue only GET; the ability to send any request that changes state is a separate, licensed capability that cannot be obtained without the Deep profile and the Section 4A acknowledgement, and no check can reach it otherwise. Data on your systems can therefore change only where your own application changes state in response to a read — a page view that writes an audit entry, a last-seen timestamp, a counter. The exclusions in Section 6.1 — log-out, delete, remove, revoke and deactivate paths are kept out of the crawl — apply to every such Scan.

Section 6's broader warning stands as a statement of risk, and governs any scheduled Scan that also carries (a) or (b): the writes described in Section 4D remain governed by Section 4B, and the form submissions described in Section 4A.1A require the Section 4A acknowledgement.

4E.4B It lapses when the credentials do. Removing or replacing the stored credentials for an Asset withdraws the authenticated-testing authorisation for it. You authorised testing with the account you supplied, not with whatever account is supplied next, so a new credential requires the authorisation to be given again.

4E.5 Who may give it, and what you confirm. By giving a standing authorisation you confirm everything you would confirm under Sections 4A.3 and 4B.8 in respect of a single Scan, and in addition that you hold authority to authorise that testing on a recurring basis, and without further notice to you before each Scan, for as long as the authorisation stands.

You will revoke it — promptly, and without waiting to be asked — when your authority to have given it ends. That includes when the account you supplied is withdrawn, disabled or rotated; when your engagement with the Asset's owner or operator ends; and when the authorisation you rely on under Section 2.1(a) lapses, is narrowed or is withdrawn. Revocation is always available under 4E.9 and is never refused.

4E.6 What it does not do. A standing authorisation:

applies only to scheduled Scans of the named Asset — it does not widen scope under Section 3, and a Scan you launch yourself is unaffected by it; the Deep and penetration-test levels apply only to the periodic full re-audit, and the authenticated level to every scheduled Scan (4E.4A);
relaxes none of the prohibitions in Section 5;
does not alter the scope guard, the rate limits, or any other control in Sections 3 and 7; and
does not extend to any Asset other than the one it names.

4E.7 Testing window. When you give a standing authorisation you may set a daily window during which scheduled intrusive Scans of that Asset may start, and we will start them within it. If you set none, the default is 01:00 to 05:00 UTC. We do not hold a timezone for your account and do not infer one, so that default is unlikely to be the quiet part of your day — for example it is 06:30 to 10:30 in India — and you should set your own window. Section 7 continues to govern the source and control of the traffic.

The window governs the levels that send attack traffic — (a) and (b). It does not restrict the authenticated level on its own, because an authenticated Scan that is not also a Deep Scan sends no attack payloads and is excluded by Section 6.1 from the state-changing paths, and because a session applied on some days and not others would corrupt the change detection this product is sold on. Where the authenticated level is combined with (a) or (b), the Scan that carries them is intrusive and the window applies to it.

4E.8 It stops when what it rests on stops. Two different things happen, and which one applies matters:

Suspended, and resumes on its own. While the Asset's verification has lapsed or been withdrawn, or while you have paused monitoring for it, the authorisation authorises nothing — no scheduled Scan of that Asset is intrusive or authenticated for as long as that is true. It resumes, without a further act by you, when verification is re-established or monitoring is resumed. We do it this way because asking you to consent again after a week's pause is friction you did not ask for.
Ended, and only a fresh grant brings it back. Removing the Asset, the ending of your subscription, and — for the authenticated level — removing or replacing the stored credentials (4E.4B) each end the authorisation. There is nothing left to resume: if you return, you will be asked again.
The authenticated level also expires on its own, twelve months after you give it. A permission to use someone's login unattended should not be capable of outliving the arrangement it was given under by years, and nobody remembers a decision made that long ago. We stop using the account and ask you again. The other levels do not expire on a clock; they end for the reasons in (b).

4E.9 Revocation. You may revoke a standing authorisation for an Asset at any time, from your account. Revocation takes effect immediately: no further scheduled intrusive Scan of that Asset is started, and any such Scan already running against that Asset is stopped as soon as practicable. Revoking a standing authorisation does not remove the Asset, end your monitoring of it, or affect any Scan you launch yourself.

4E.10 Re-affirmation on amendment. A standing authorisation is pinned to the version and text hash of this RoE in force when you gave it. When we issue any new version of this RoE, every standing authorisation given under an earlier version stops taking effect until you give it again under the new one. This is deliberately blunt — it does not ask anyone to judge whether a change was material — so a correction of any size re-opens the question, and you are never testing under wording you did not agree to. Consistent with Section 12.4, a later version never retrospectively widens what you authorised under an earlier one.

4E.11 You are told what ran. A Scan performed under a standing authorisation is reported to you in the same way as a Scan you launch. The append-only audit record for that Scan identifies the level that authorised it and the date you gave that authorisation (Section 12.2), and the authorisation itself, with the date and a control to withdraw it, is shown on the Asset's page in your account.

5. Methods we will not use

The following are prohibited and disabled, and are not authorised by this RoE under any circumstances — including under the penetration-test tier:

denial of service, distributed denial of service, stress or load testing;
destructive actions of any kind — deletion, encryption, corruption or overwriting of data, defacement, or disabling of services or accounts;
stored or persistent payloads — any payload designed to remain in your application or to be served to another user;
establishing persistence: backdoors, shells, implants or scheduled tasks;
lateral movement or pivoting beyond the Authorised Asset;
bulk extraction of data;
social engineering, phishing or any activity directed at a person;
physical or wireless attacks;
attacks against a third party, including other tenants of shared infrastructure.

Payloads are bounded, per-asset rate limits are enforced, and scan windows are respected. Where a scanning tool offers a mode or template that would breach this Section, that mode or template is disabled in our configuration and its invocation is refused by our safety policy.

6. Credentials for authenticated testing

6.1 If you supply credentials for an Asset, and give the authenticated-testing acknowledgement — either for a specific Scan or in advance for that Asset under Section 4E — then:

issue dedicated test accounts with the least privilege needed;
never supply production administrator or superuser credentials;
expect them to be used to log in and exercise authenticated functionality, which may create, modify or delete data within that account's own permissions;
expect the crawler to carry that session on every request, so that testing reaches every page and endpoint the account can see — materially more of your application than an unauthenticated Scan. Links that would end the session or that appear to be state-changing (for example log-out, delete, remove, revoke or deactivate paths) are excluded from the crawl;
where the penetration-test acknowledgement is also given, expect the session to be used for the reads described in Section 4B.5 and the writes described in Section 4D;
revoke them when you stop testing.

6.2 Credentials are stored encrypted, are used only at the egress boundary for the host they belong to, are never sent to a language-model provider, and are never included in Findings, evidence or Reports. You remain responsible for the consequences of the access you grant.

An authenticated Scan reaches pages that an unauthenticated one cannot, and may therefore bring personal data of your own users into the evidence attached to a Finding. We process it for you, on your instructions, as described in the Privacy Policy. Where the Asset belongs to someone else, you are responsible for ensuring your own arrangement with them permits that processing and permits engaging us to carry it out.

6.3 The account you supply — what you warrant about it. Section 2.1(a) is a warranty about the Asset. This one is about the account, because authority over a system and authority over a login are not the same thing and the second is what authenticated testing actually turns on.

On each occasion you store credentials for an Asset, and on each occasion you give the authenticated-testing authorisation under Section 4E, you represent and warrant that:

the account was issued or approved by the Asset's owner and operator for security testing, and is held for that purpose;
it is not the account of any natural person and not the account of a real user of the Asset — not a colleague's login, not a customer's, not your own everyday account;
you are entitled to use it and entitled to permit us to use it as described in Section 6.1; and
where the Asset does not belong to you, the written authorisation you hold under Section 2.1(a) expressly extends to authenticated testing with that account, and, where you give a standing authorisation under Section 4E, to its recurring and unattended use.

Supplying an account you are not entitled to supply is a breach of this RoE, and Section 11 applies to it. No acknowledgement you give us can create an authority you do not have: the only permission that matters for access to a system is the permission of the person entitled to give it.

7. Source of traffic, timing and control

7.1 Source. Test traffic originates from the dedicated address in Section 4C.4 and is identifiable in your logs as SecQon.

7.2 Notify your defenders. For all testing, on every tier, you should tell your hosting provider, security operations team, managed detection provider and WAF vendor before your first scan — unless you are deliberately testing whether they notice, which is a legitimate reason not to. A Scan does not need the Deep profile to trip a sensitive firewall (Section 4C.1). For the penetration-test tier, this is not a recommendation: Section 4C applies.

7.3 Timing. Scans run in the windows and at the intensity your plan and profile allow. Choose a low-traffic window for your first scan of a production system, and for every Scan under Section 4B.

7.4 Stopping a scan. You can stop any running scan from the application at any time. For anything urgent — including a report that we are testing a system that should not be tested — contact abuse@secqon.com, and we will activate the kill switch for the account and halt in-flight jobs.

7.5 Our right to stop. We may pause or stop testing at any time if we believe it is causing harm, is out of scope, is generating third-party complaints, or is not properly authorised.

8. Risks you accept

Security testing carries inherent risk. Although SecQon is designed to be non-destructive, bounded and rate-limited, you acknowledge and accept that testing of your Authorised Assets may:

degrade performance or increase latency during a scan;
trigger application errors, exceptions and unexpected behaviour, including — under Section 4B — errors caused by your application partially processing a working attack payload;
generate large volumes of log entries, alerts and security notifications, including pages to your on-call staff, and including alerts that are indistinguishable from a genuine attack;
cause your hosting provider, cloud provider, CDN or WAF vendor to raise an abuse report, throttle, suspend or terminate your service on the basis of the traffic you authorised;
cause a WAF, CDN, rate limiter or upstream provider to block our traffic — or, in some configurations, to block or throttle other traffic, including your legitimate users';
cause account lockouts or rate-limit responses on authentication endpoints;
write test data into forms, records, queues, tickets, analytics or email triggered by your application, and — under Section 4D — change a privileged field on the record of the account whose credentials you supplied;
leave attack payloads in your logs and error-tracking systems, which you may need to explain to your own auditors, customers or regulators;
in rare cases, cause a service to become temporarily unavailable.

You accept these risks in respect of your own Authorised Assets, and you are responsible for maintaining current backups and for choosing an appropriate scan window, profile and tier. Where an Asset is business-critical, test a staging equivalent first, and give the penetration-test acknowledgement for a production Asset only after you have done so.

9. Your responsibilities

Add only Assets you are entitled to authorise, and keep that entitlement current.
Keep verification records in place; if a DNS TXT record or hosted token is removed, verification lapses and testing stops.
Maintain a technical contact on the account who can be reached quickly, and — for the penetration-test tier — who is available during the Scan.
Maintain current backups and a rollback path.
Inform the people who will see the alerts, and — for the penetration-test tier — obtain provider consent and give provider notice as Section 4C.2 requires, before the Scan runs.
Remove an Asset immediately if your authority over it ends or is contested, and tell us at abuse@secqon.com.
Give an acknowledgement under Section 1.4 only if you have read the Section it refers to and hold the authority described in Section 4B.8.

10. Term, revocation and survival

10.1 This RoE takes effect when you accept it and continues for each Asset for as long as that Asset is verified and your account is active.

10.2 You may revoke authorisation at any time for an Asset by removing it, by revoking a standing authorisation under Section 4E.9, or entirely by closing your account. Revocation is effective immediately for new scans; in-flight scans are stopped as soon as practicable.

10.3 Sections 2, 4C.3, 4E.5, 6.3, 8, 11 and 12 survive revocation and termination.

11. Indemnity

11.1 You defend, indemnify and hold harmless Infiqon, its affiliates, and their directors, officers, employees, contractors and agents against all third-party claims and resulting losses, liabilities, damages, fines, penalties, settlements and reasonable legal and expert costs arising out of or relating to:

testing of a system you were not entitled to authorise, or testing in excess of the authorisation you actually held, including penetration testing under Section 4B of an Asset whose owner or operator had not authorised testing of that kind;
your breach of this RoE, the Acceptable Use Policy, or Section 5 of the Terms, including a breach of the warranties in Sections 2.1, 4C.3 and 6.3;
any effect of authorised testing on any system or on any third party, including disruption, downtime, data alteration or data loss, and including claims by your own customers, users, or by a hosting, cloud, CDN, WAF, DNS or transit provider or another tenant of shared infrastructure;
any abuse complaint, service suspension, service termination or reputational action taken by a provider or third party in response to traffic you authorised, including any cost to Infiqon of responding to it; and
any regulatory or law-enforcement action arising from your use of SecQon, including under India's Information Technology Act, 2000 or any equivalent computer-misuse or cybercrime law of any jurisdiction.

11.2 This indemnity is the same obligation as Section 15 of the Terms, restated here because it is the consequence of the authorisation you are giving. Section 15.2 of the Terms governs the defence procedure, the indemnity is not subject to the liability cap, and it survives termination.

11.3 It does not apply to the extent the loss is caused by our gross negligence or wilful misconduct, by our testing of a target outside the scope you authorised, or by our use of a method that this RoE states we will not use.

12. Legal compliance and record

12.1 You confirm that the testing authorised here, including any testing under Section 4B, does not breach any applicable law, including the Information Technology Act, 2000 (India) and equivalent computer-misuse, unauthorised-access and data-protection legislation in any jurisdiction where an Asset is hosted, operated or reachable. You acknowledge that in many jurisdictions the sending of attack payloads to a computer system is a criminal offence unless authorised by the person entitled to authorise it, and that this RoE and your acknowledgements are the authorisation on which Infiqon relies.

12.2 Every authorisation event is recorded in an append-only, cryptographically chained audit log: your acceptance of this RoE and its version and text hash; the per-asset attestation you make when adding each Asset; the per-scan attestation you make when launching each Scan; each Deep, authenticated-testing and penetration-test acknowledgement you give, with the RoE version and text hash in force at the time; the grant and the revocation of every standing authorisation under Section 4E; every verification result; and every out-of-scope denial by the scope guard. These records are our evidence, and yours, that testing was authorised.

12.3 You agree that this electronic record is a valid electronic record and signature under the Information Technology Act, 2000 and the Indian Contract Act, 1872.

12.4 Re-acceptance. When we issue a new version of this RoE you will be asked to accept it before launching a further Scan. A new version does not retrospectively widen the authorisation you gave under an earlier one; testing first described in a later version is authorised only from your acceptance of that version.

What you are agreeing to, in plain language

We only test what you have proven you control and told us you may authorise.
You are telling us you have the right to authorise it — and you carry the consequences if that turns out not to be true.
We will never do anything destructive, and we will stop the moment you ask.
The Deep profile actively tries to prove exploits — but only bounded, non-destructive ones, and only once you acknowledge that, either on the specific scan or in advance for that asset.
The penetration-test tier sends real attacks. Path traversal, command injection, SQL injection and the rest — the real thing, bounded and non-destructive, but real. It also deliberately trips your firewall to see whether it works, and if you gave us a login it may change one field on that login's own record to prove a bug. It needs its own separate tick-box — never bundled with the Deep one — and your providers must be told first.
You can let scheduled scans do the intrusive work without asking each time. That is a deliberate, per-asset choice you make after proving you own the asset, it is never on by default, you can set the hours it runs in, and you can withdraw it at any moment — which also stops a scan already in progress.
You can do the same for logging in. Separately, and in either order: authorising us to test behind your login is not authorising attack payloads, and authorising attack payloads is not authorising us to log in. The login one applies to every scheduled scan rather than only the monthly deep one, because a scan that authenticates sees far more of your app and switching between the two would make our change detection cry wolf. On its own it only ever reads — sending anything that writes needs the deep tick-box as well. Change the stored credentials and you will be asked again, and it expires after a year anyway.
The login you give us must be a test account the app's owner issued for this. Not a colleague's, not a real user's, not your own everyday one. If the app belongs to a client, your authorisation from them has to cover us logging in — and, if you turn on the standing version, cover us doing it unattended. Getting that wrong is on you, and nothing you tick here can fix it: the only permission that counts is the owner's.
Testing can still cause disruption, and you accept that risk for your own systems — including the alerts, abuse reports and provider reactions that real attack traffic produces. Even an ordinary scan can set off a sensitive firewall, so tell your defenders before the first one.
Every one of these authorisations is logged, with the exact text you accepted.

Emergency stop and abuse: abuse@secqon.com · Questions: legal@secqon.com